Geoff Huston, chief scientist at APNIC, writes about IPv4 exhaustion, the IPv6 transition, DNS, QUIC, and internet routing data.
HN links it mainly for its IPv4 address tracking tools and infographics, used as a reference in discussions of address exhaustion.
This kind of thing seems innocent, but it really isn't.
Another comment put it as "25.x.x.x is not advertised globally, not announced with BGP, so they're using it as private IP space. This works because you will never connect to a 25.x.x.x IP. It's just NAT."
That sounds fine but you run into trouble when the owner suddenly starts using the space or it’s reallocated. This has happened quite a lot in the last decade as IP space was ever more in demand and thus ever more scarce. An example is the use of 1.0.0.0/8 - allocated to APNIC in 2010 - there is a detailed analysis of the "unintentional" traffic this network was receiving when first used https://www.potaroo.net/studies/1slash8/1slash8.html - over 165 megabits in 2010.
Among various lazy configs and people using the range as it was convenient I recall there was some default popular Cisco recommended config that used it. Though I can’t find a link right now.
Similar problems also happened in the 2007-2010 timeframe as a lot of people used to have static “Bogon filter” firewalls that dropped traffic from unallocated IP ranges (not those marked as 'never to be used', just those not allocated yet). As more and more ranges were allocated the people receiving them had all sorts of connectivity problems to random networks because of these old out of date static filters - in my experience as a hosting provider the most common offender was banks hilariously. In practice these filters provided relatively little security and…
"market based allocation" - this means further deaggregation of the existing prefixes.
Which translates into eventual serious capital expenditures for the carriers to hold the large tables. Worldwide.
In addition to the money required to pay for carrier grade translators. Though my employer produces them (amongst other stuff) - I do not think that architecturally they are a good thing.
All this money will need to come from somewhere. As the profit from a "prefix sold" goes into one pocket, but the expenditures are spread around the world, it means this profit would not come from IP addresses. It will come from the subscribers' monthly payments and quotas.
Translating: bye bye unmetered access on the cheap. Not so long ago in .be the ISPs were charging after you go over 10Gb on the DSL line.
About squeezing out the /8s from the current owner: that would help but not for long. It's like getting the additional credit line from the bank on the credit card.
For some info on the exhaustion and the models used you can take a look here: http://www.potaroo.net/tools/ipv4/
Of course, NATs are "convenient", so I would not necessarily exclude that some will decide to go with the scenario you describe - cascaded NATs.
I share your pain, bro :)
Although, two corrections:
1) prices are, in my experience, lower than what you quoted: around 10-12 $/IP, depending on the subnet size.
2) RIPE is indeed encouraging the marketplace model: it is seen as a mechanism to move resources to LIRs that need them the most, with the side effect of increasing IP efficiency.
Also, to note:
4) Since some time, there is a policy proposal [1] to allow intra-RIR transfers to/from RIPE. I'm not aware on whether there is such a proposal within ARIN, which currently allows only transfers to/from APNIC (not very useful if you're american... addresses in APNIC ended a long time ago!).
5) RIPE currently operates in a "emergency policy" that allows a /22 to new registrants and a /24 to new members. ARIN will follows the same policy as soon as they remain with a single /8 left (probably around May-June 2014).
6) I always like to give a link to the very informative exhaustion graph of Geoff Huston [3] :)
[1] http://www.ripe.net/ripe/policies/proposals/2012-03
[2] https://www.arin.net/resources/request/transfers_8_4.html
[3] http://www.potaroo.net/tools/ipv4/index.html
The rabbit hole on people gradually pulling up stakes on DNSSEC goes deeper than that; I'd say the canary in the coal mine is probably Geoff Huston switching from "of course we're going to DNSSEC everything" to "are we going to DNSSEC anything?":
https://www.potaroo.net/ispcol/2023-02/dnssec.html
(Geoff Huston is an Internet infrastructure giant.)
But really it all just boils down to the fact that the DNS zones that matter --- the ones at the busy end of the fat tail of lookups --- just aren't signed, despite 25 years of work on the standard. IPv6 is gradually mainstreaming; in countries where registrars auto-sign zones, DNSSEC is growing too, but very notably in countries where people have a choice, DNSSEC deployment is stubbornly stuck in the low single digit percentages, and the zones that are getting signed are disproportionately not in the top 10,000 of the Tranco list.
"signed with DNSSEC" is an ambiguous statement. You need to take into account that, while nameservers may enable DNSSEC, resolvers may:
(a) validate (include the AD bit) but strip the RRSIGs (i.e. regular DNSSEC resolver)
(b) omit the AD bit but include the RRSIGs (i.e. you have to validate yourself)
(c) omit the AD bit and omit the RRSIGs (i.e. regular non-DNSSEC resolver)
(d) validate (i.e. include the AD bit) and include the RRSIGs (i.e. alleluia!)
My own study [0] (using the Atlas network [1]) found 30% of resolvers doing (a), and 65% doing (b), including some overlap. There are people way more qualified than me doing this kind of stuff, namely APNIC's Geoff Huston, see [2] for instance.
[0] https://www.os3.nl/_media/2013-2014/courses/rp2/p14_report.pdf
[1] https://atlas.ripe.net
[2] http://www.potaroo.net/presentations/2014-06-03-dns-measurements.pdf
It's worth pointing out, in terms of LE being "wildly more successful", that this represents a single organisation, with a security critical role on the web, approaching a monopoly. That's actually a worse situation than if 100% of hosts on the internet supported (different but compatible implementations of) IPv6.
Here is a chart showing the trend for LE marketshare (under the IdenTrust root):
https://w3techs.com/technologies/history_overview/ssl_certificate
I really support LE's mission, and celebrate their success, but would feel more comfortable if a separate organisation tried replicating what they had done, running the same service but with distinct personnel and assets.
For reference, here is another chart showing the run down of the remaining IPv4 supply:
http://www.potaroo.net/tools/ipv4/plotend.png