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.
On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen <aychen@avinta.com> wrote:
Hi, Enno:
0) Thanks for your comments referring to historical efforts.
1) However, the "IPv4 Unicast Extension Project" that your paper cited does not make any specific recommendation about how to utilize the 240/4 netblock uniformly across the entire Internet. Our proposal, EzIP outlines a scheme that makes a clear use of the 240/4 by the general public, basically discouraging disparate private usages. We were very much lost with what has been going on with the 240/4 netblock, because there was no information about who were using it for what. The RIPE-Lab report clarified the fact that it has been fragmented due to unannounced activities by multi-national conglomerates and likely nerds, while under the cover of "Reserved for Future Use".
2) " As you state yourself this could be considered "unorthodox, if not controversial". ... usually means 'breaks something' ":
I am afraid that you read into my diplomatic expression too far.
A. The first step of the EzIP proposal is to enhance the CG-NAT by providing it with a much larger netblock, as I presume that Karim is looking for. Such process (disabling the program code that has been disabling the use of 240/4) does not need any running code to prove it. To be blunt, anyone who claims that this will be a real task only shows that he does not know his own code.
B. The second EzIP step is to utilize RFC791 for setting up end-to-end links which the Internet has not been able to deliver. This is because the current predominant CG-NAT based CDN business is a master-slave model which does not support it. However, this capability is like international postal or telephony services that are not daily needs for everyone. So, it should be treated as a premium service that can be built up with time base on demand.
Let's not mixing B. with A. as a one-shot job in this discussion.
Regards,
Abe (2024-01-10 22:10 EST)
On 2024-01-10 07:57, Enno Rey via NANOG wrote:
On Wed, Jan 10, 2024 at 07:35:01AM -0500, Abraham Y. Chen wrote:
Hi, Karim:
1)?????? If you have control of your own equipment (I presume that your business includes IAP - Internet Access Provider, since you are asking to buy IPv4 blocks.), you can get a large block of reserved IPv4 address _/*for free*/_ by _/*disabling*/_ the program codes in your current facility that has been */_disabling_/* the use of 240/4 netblock.
As you state yourself this could be considered "unorthodox, if not controversial". Alas in network operations 'unorthodox' usually means 'breaks something'. Which is exactly why you may avoid this, see also:
https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-...
cheers
Enno
Please
have a look at the below whitepaper. Utilized according to the outlined disciplines, this is a practically unlimited resources. It has been known that multi-national conglomerates have been using it without announcement. So, you can do so stealthily according to the proposed mechanism which establishes uniform practices, just as well.
https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
2)?????? Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests.
Regards,
Abe (2024-01-10 07:34 EST)
On 2024-01-07 22:46, KARIM MEKKAOUI wrote:
Hi Nanog Community
Any idea please on the best way to buy IPv4 blocs and what is the price?
Thank you
KARIM
-- This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com>
<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_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>