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. 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.
2) Being an unorthodox solution, if not controversial, please follow up with me offline. Unless, other NANOGers express their interests.
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:
Please be cautious about this advice, and understand the full context.
240/4 is still classified as RESERVED space. While you would certainly be able to use it on internal networks if your equipment supports it, you cannot use it as publicly routable space. There have been many proposals over the years to reclassify 240/4, but that has not happened, and is unlikely to at any point in the foreseeable future.
Mr. Chen-
I understand your perspective surrounding 240/4, and respect your position, even though I disagree. That being said, itâs pretty dirty pool to toss this idea to an operator clearly looking to acquire publicaly routable space without being clear that this suggestion wouldnât meet their needs.
( Unless people are transferring RFC1918 space these days, in which case who wants to make me an offer for 10/8? )
While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge.
There's a whole bunch of software out there that makes certain assumptions about allowable ranges. That is, they've been compiled with a header that defines ..
Thereâs a whole bunch of software out there that makes certain
assumptions about allowable ranges. That is, theyâve been compiled with
a header that defines âŚ
Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same.
Itâs consistently a topic in the debates about 240/4 reclassification.
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\.
1) Your caution advice to Karim is professional. With a lot of convoluted topics behind it, however, the net result is basically discouraging the listener from investigating the possibilities. Since this is rather philosophical, it can distract us from the essence unless we carry on a lengthy debate. Instead, I would like to address below only one aspect that you brought up.
2) "... an operator clearly looking to acquire *publicly routable* space without being clear that this suggestion wouldn't meet their needs. ":
Since 240/4 has 256M addresses while 100\.64/10 has only 4M, a current CG\-NAT cluster can be expanded 64 fold once the 240/4 is used\. Looking from another angle, an IAP will then be able to expand the subscriber set 64 fold with still the original one publicly routable IPv4 address\.
3) This 64 fold scaling factor is critical because it allows one CG-NAT cluster to serve a geographical area that becomes sufficient to cover a significant political territory. For example, if we assign two 240/4 addresses to each subscriber, one for stationary applications, one for mobile devices. And, each 240/4 address can be expanded by RFC1918 netblocks (total about 17.6M each). Each CG-NAT can now serve a country with population up to 128M. It turns out that population of over 90+ % of countries are fewer than this. So, each of them needs only one publicly routable IPv4 address. Then, the demand for IPv4 address is drastically reduced.
4) In brief, the 240/4 is to substitute that of 100.64/10. So that the need for the publicly routable IPv4 addresses is significantly reduced.
"⌠an operator clearly looking to acquire publicly routable space without being clear that this suggestion wouldnât meet their needs. ":
Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from another angle, an IAP will then be able to expand the subscriber set 64 fold with still the original one publicly routable IPv4 address.
The OP asked for âAny idea please on the best way to buy IPv4 blocs and what is the priceâ. I would expect they want actual public IPv4 address blocks and not internal CGNAT space. While the idea of using 240/4 instead of 100.64/10 would certainly have some merit I donât believe its in any way related to what this OP asked for.
There is no need to run one giant cluster. Many small clusters with VRFs and CG-NAT devices to bridge the gap from the VRF to the Internet and keep the blast radius small, are enough. A CG-NAT ISP should not need to work so hard to provide a unique enough CG-NAT IP address, as long as they can match a MAC address of the customer router + MAC address of the carrier equipment, to the DHCP and flow logs.
As along as the carrier implements IPv6, it will cut down on the active NAT sessions and port forwards the equipment needs to process.
It has been known that multi-national conglomerates have been using it without announcement.
This is an assurance that 240/4 would never be permitted for Public Internet. These âmulti-national congloâ has enough influence on the IETF to not permit it.
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.
There's a whole bunch of software out there that makes certain
assumptions about allowable ranges. That is, they've been compiled with
a header that defines ..
Of course correct. It really depends on the vendor / software / versions in an environment. A lot of vendors removed that years ago, because frankly a lot of large networks have been using 240/4 as pseudo RFC1918 for years. Others have worked with smaller vendors and open source projects to do the same.
It's consistently a topic in the debates about 240/4 reclassification.
There's debates still? I gave up. After making 240/4 and 0/8 work
across all of linux and BSD and all the daemons besides bird (which
refused the patch , I took so much flack that I decided I would just
work on other things. So much of that flack was BS - like if you kill
the checks in the OS the world will end - that didn't happen. Linux
has had these two address ranges just work for over 5 years now.
240/4 is intensely routable and actually used in routers along hops
inside multiple networks today, but less so as a destination.
I would really like, one day, to see it move from reserved to unicast
status, officially. I would have loved it if 0/8 was used by a space
RIR, behind CGNAT, for starters, but with a plan towards making it
routable. I am not holding my breath.
The principal accomplishment of the whole unicast extensions project
was to save a nanosecond across all the servers in the world on every
packet by killing the useless 0/8 check. That patch paid for itself
the first weekend after that linux kernel deployed. It is the
simplest, most elegant, and most controversial patch I have ever
written.
There really is no reason for 240/4 to remain âreservedâ. I share Daveâs views, I would like to see 240/4 reclassified as unicast space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held until their issues have been resolved.
Reclassifying this space, would add 10+ years onto the free pool for each RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of a /8 pool available for delegation, another 1/6th reserved. Reclassification would see available pool volumes return to pre-2010 levels.
Just enough time for us to retire comfortably and let some other fool
fix the mess we built?
We don't need to extend IPv4, we need to figure out why we are in this
dual-stack mess, which was never intended, and how to get out of it.
We've created this stupid anti-competitive IPv4 market and as far as I
can foresee, we will never organically stop using IPv4. We've added
CAPEX and OPEX costs and a lot of useless work, for no other reason,
but our failure to provide a reasonable solution going from IPv4 to
IPv6.
I can't come up with a less stupid way to fix this, than major players
commonly signing a pledge to drop IPv4 in their edge at 2040-01-01, or
some such. To finally create an incentive and date when you need to
get your IPv6 affairs in order, and to fix the IPv4 antitrust issue.
Only reason people need IPv4 to offer service is because people
offering connectivity have no incentive to offer IPv6. In fact if
you've done any IPv6 at all, you're wasting money and acting against
the best interest of your shareholders, because there is no good
reason to spend time and money on IPv6, but there should be.
We don't need to extend IPv4, we need to figure out why we are in this
dual-stack mess, which was never intended, and how to get out of it.
Few have figured out how to reliably deliver IPv4 over a IPv6 network,
and customers need IPv4 more than they need IPv6.
There is no easy way for an ISP to provide a /48 with an IPv4 /32 on
top, either using tunnelling or translation, and have the majority of
CPEs just work.
DNS64 and NAT64 are successful for mobile operators, and handsets
generally handle everything seamlessly. The wired world is not so lucky.
measured by IANA was ~13 per annum. So that suggests that 240/4 would provide a little more than 1Y of consumption, assuming no demand back-pressure, which seems an unlikely assumption.
Your caution advice to Karim is professional. With a lot of convoluted topics behind it, however, the net result is basically discouraging the listener from investigating the possibilities.
No, it is not.
The original question from Karim was about acquiring some IPv4 space. We can absolutely infer he wanted that space to be publically routable today.
The facts are that today :
240/4 is not space that will provide expected internet connectivity
There are no plans or timelines in place that would change #1.
You stated to Karim that there was a way he could get IPs for free , and implied if he reached out to you off list , you could help him make it work. That was intentionally misleading, and frankly doesnât reflect very well on you at all.