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

[Christopher Hawker <chris () thesysadmin au>]

"Source NAT changes the source address in IP header of a packet. It may
also change the source port in the TCP/UDP headers. The typical usage is to
change the a private (rfc1918) address/port into a public address/port for
packets leaving your network."

"Destination NAT changes the destination address in IP header of a packet.
It may also change the destination port in the TCP/UDP headers.The typical
usage of this is to redirect incoming packets with a destination of a
public address/port to a private IP address/port inside your network."

Source:
https://serverfault.com/questions/119365/what-is-the-difference-between-a-source-nat-destination-nat-and-masquerading

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 23:17, Abraham Y. Chen <aychen () avinta com> wrote:

> Hi, Christopher:
>
> 1)   "  destination/source NAT  ":
>
>     I am not sure about this terminology. Could you please elaborate? If
> you are referring EzIP being a bigger CG-NAT, it is exactly correct. That
> is, the first step of EzIP implementation is just to give CG-NAT a larger
> netblock to work with, so that the chore of dynamic address assignment to
> the client may be avoided.
>
> Regards,
>
> Abe (2024-01-12 07:16)
>
>
>
> On 2024-01-11 22:46, Christopher Hawker wrote:
>
> Not going to lie, EzIP just seems to be some version of destination/source
> NAT on steroids.
>
> Regards,
> Christopher Hawker
>
> On Fri, 12 Jan 2024 at 14:36, 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.
> >
> >
> >
> >
> >
> > > <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_7003280393758044796_m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>