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

Fri Jan 12 12:30:46 UTC 2024

"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 at 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 at 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>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240112/2746d1bf/attachment.html>