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 <ayc...@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-address-space/
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>
