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:

Thanks for the confirmation.

Regards,


Abe (2024-01-13 11:42)


On 2024-01-12 07:30, Christopher Hawker wrote:
> "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>


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