"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 <ayc...@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 <ayc...@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> >>> >> >> >