Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

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

The problem isn't the quantity of "inside" CG-NAT address space.  It's the
existence of CG-NAT at all.

It doesn't matter if the available space is a /12 or a /4, you still need
something to translate it to the public internet.   The existence of that
CG-NAT box is a thorn in every provider's side and every provider that has
one wants to make it go away as quickly as possible.

The quickest and most straightforward way to eliminate the need for any
CG-NAT is to move to a bigger address space.  As I pointed out, IPv6 is
already ready and proven to work so moving to IPv6 is a straightforward
process technically.  What isn't straightforward is convincing IPv4 users
to move.  Until the cost (or pain) to stay on IPv4 is greater than the cost
to move,  we're going to see continued resistance to doing so.


On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen () avinta com> wrote:

> Hi, Forrest:
>
> 0)    Thanks for your in-depth analysis.
>
> 1)     However, my apologies for not presenting the EzIP concept clearer.
> That is, one way to look at the EzIP scheme is to substitute the current
> 100.64/10  netblock in the CG-NAT with 240/4. Everything else in the
> current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
> fold bigger. And, various capabilities become available.
>
> Regards,
>
> Abe (2024-01-11 22:35)
>
>
>
> On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
>
> I shouldn't probably go down this path... as I know this has been
> discussed but I'm hoping that this might make a difference.
>
> Abraham,
>
> Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT
> box between the 240/4 addressed devices and the non-EzIP internet.  That
> NAT box will have to remain in place until such time as every single
> publically addressed device on the public internet has been updated to
> support EzIP.  In addition, protocols such as DNS, SIP, and others which
> pass around addresses will need to be updated to be able to pass the full
> EzIP addressing around so endpoints can properly insert the EzIP header,
> and so on.
>
> The point I'm trying to make is that, at this point, deploying EzIP as an
> end to end address exhaustion solution has MORE challenges that simply
> deploying IPv6 would.  This is because, just like EzIP, deploying IPv6
> requires a NAT box of some sort to be put in place until the last IPv4
> device is turned off.   But unlike EzIP, almost every new device coming out
> supports IPv6 out of the box.   All of the technical standards work has
> already been done.   Thus, the only meaningful barrier to IPv6 at this
> point is convincing people to use it, not convincing people to use it PLUS
> convincing the tech companies to support it,  and doing protocol changes
> like you would with EzIP.
>
> I applaud your attempt at a unique solution but I really feel that ship
> has sailed, at least for an EzIP type of solution. Maybe something like
> this would have better received years ago, but at this point IPv6 is a much
> more logical path forward.
>
> I do wonder,  however,  if some of your concepts might be able to be
> applied to the IPv6 transition.  I have some ideas here,  but most, if not
> all, of them are only partially cooked but some have similar approaches as
> EzIP but with an actual IPv6 packet inside.
>
>
>
> On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen <aychen () avinta com> wrote:
>
> > Hi, Enno:
> >
> > 0)    Thanks for your comments referring to historical efforts.
> >
> > 1)    However, the "IPv4 Unicast Extension Project" that your paper cited
> > does not make any specific recommendation about how to utilize the 240/4
> > netblock uniformly across the entire Internet. Our proposal, EzIP outlines
> > a scheme that makes a clear use of the 240/4 by the general public,
> > basically discouraging disparate private usages. We were very much lost
> > with what has been going on with the 240/4 netblock, because there was no
> > information about who were using it for what. The RIPE-Lab report clarified
> > the fact that it has been fragmented due to unannounced activities by
> > multi-national conglomerates and likely nerds, while under the cover of
> > "Reserved for Future Use".
> >
> > 2)    " As you state yourself this could be considered "unorthodox, if
> > not controversial". ... usually means 'breaks something' ":
> >
> >     I am afraid that  you read into my diplomatic expression too far.
> >
> >     A.    The first step of the EzIP proposal is to enhance the CG-NAT by
> > providing it with a much larger netblock, as I presume that Karim is
> > looking for. Such process (disabling the program code that has been
> > disabling the use of 240/4) does not need any running code to prove it. To
> > be blunt, anyone who claims that this will be a real task only shows that
> > he does not know his own code.
> >
> >     B.    The second EzIP step is to utilize RFC791 for setting up
> > end-to-end links which the Internet has not been able to deliver. This is
> > because the current predominant CG-NAT based CDN business is a master-slave
> > model which does not support it. However, this capability is like
> > international postal or telephony services that are not daily needs for
> > everyone. So, it should be treated as a premium service that can be
> > built up with time base on demand.
> >
> >     Let's not mixing B. with A. as a one-shot job in this discussion.
> >
> > Regards,
> >
> >
> > Abe (2024-01-10 22:10 EST)
> >
> >
> >
> >
> >
> > On 2024-01-10 07:57, Enno Rey via NANOG wrote:
> >
> > On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote:
> >
> > Hi, Karim:
> >
> > 1)?????? If you have control of your own equipment (I presume that your
> > business includes IAP - Internet Access Provider, since you are asking
> > to buy IPv4 blocks.), you can get a large block of reserved IPv4 address
> > _/*for free*/_ by _/*disabling*/_ the program codes in your current
> > facility that has been */_disabling_/* the use of 240/4 netblock.
> >
> > As you state yourself this could be considered "unorthodox, if not controversial".
> > Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, 
> > see also:
> > https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/
> >
> > cheers
> >
> > Enno
> >
> >
> >
> >
> >
> >  Please
> >
> > have a look at the below whitepaper. Utilized according to the outlined
> > disciplines, this is a practically unlimited resources. It has been
> > known that multi-national conglomerates have been using it without
> > announcement. So, you can do so stealthily according to the proposed
> > mechanism which establishes uniform practices, just as well.
> > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
> >
> > 2)?????? Being an unorthodox solution, if not controversial, please follow
> > up with me offline. Unless, other NANOGers express their interests.
> >
> >
> > Regards,
> >
> >
> > Abe (2024-01-10 07:34 EST)
> >
> >
> >
> > On 2024-01-07 22:46, KARIM MEKKAOUI wrote:
> >
> > Hi Nanog Community
> >
> > Any idea please on the best way to buy IPv4 blocs and what is the price?
> >
> > Thank you
> >
> > KARIM
> >
> >
> > --
> > This email has been checked for viruses by Avast antivirus software.www.avast.com
> >
> >
> >
> >
> > <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_4344191822884267435_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>