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

["Abraham Y. Chen" <aychen () avinta com>]

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_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com