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_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- This email has been checked for viruses by Avast antivirus software. www.avast.com
