IPv4 Address Auctions
auctions.ipv4.global
auctions.ipv4.global
If there was a big list of all reallocatable / not-permanently-allocated IP ranges, I'd willingly — gleefully! — just dump it into Cloudflare as an IP blocklist for our website / registration flow. And there'd be zero fear in my mind of getting any false positives or user complaints by doing so.
After all, none of these reallocatable ranges are ever purchased by residential/commercial broadband ISPs; those customers would much rather solve their IPv4 problems permanently, by doing either IPv6 enablement or CGNAT, than solve them for only the next 1024 customers, by buying a piddly /22 — especially at an unpredictable, un-budget-able price!
And for registrations, any IP other than ISP IPs doesn't matter. IaaS IP? Bot. VPS IP? Bot. Colo IP? Bot. "Internal-use" IP? Bot. if someone's traffic isn't coming from an IP address owned by an ISP, then for purposes of registration, it's not good traffic, 99.999% of the time†. Those IPs are perfectly fine when it comes to actual requests — obviously, your application backend using our API is a "bot" in some sense — but your application backend shouldn't be going to our website and filling out a sign-up form. :)
(† The other 0.0001% are people using "workstation in the cloud" services. But people using those are used to being treated as second-class Internet citizens when trying to do web browsing from their cloud workstation; and they already know the solution is always to switch back to their real computer's web browser for anything requiring IP reputation.)
> The other 0.0001% are people using "workstation in the cloud" services.
Yeah, no. I've been using VPNs/SSH tunnels/proxies set up on various VPS hosters/"cloud" vendors for more than a decade to bypass heavy internet censorship. It is much cheaper than using ready-made VPN solutions, and the server can be reused for other purposes. I understand that may be <0.1% of your market, but it's not 0.
We're definitely used to being treated as third-class internet citizens not only by our own government, but also by various internet companies, which your comment demonstrates pretty clearly.
Here's a nice write-up. It's not mine, and it's not even the same country, but the experience he describes is very relatable.
https://shahinsorkh.ir/2019/07/20/how-is-it-like-to-be-a-dev...
A key property of people who aren’t willing to relinquish their anonymity for even a moment in registering for your service, is that they’ll never be able to pay money for your service, either, because doing so would reveal their identity through their credit card.
(Yes, they can use Bitcoin or whatever, but then you’re basically signing up to be a dark web business, having to deal with being a money-laundering sink for stolen funds.)
So, if your goal in getting users to sign up, is to feed them through a funnel that eventually ends up with them paying you money, then you can take “signs up using a VPN” (or an email anonymization service, or…) as an immediate self-disqualification.
Of course, most such failed attempts are innocent first-time “I didn’t realize you cared” attempts; so we just throw a clear error message, telling them to try again with their real email+IP+etc.
But when a user responds to that error by just trying more and more email proxy domains, or repeatedly rotating their VPN country… well, that’s someone who’ll never be a customer. May as well just block them and be done with it.
This is similar to for example Vodafone not listing their mobile app in countries they don't operate in so I can't install it to recharge a sim I'm going to use in a week... in one of those countries. Or ANZ bank making it hard to get their app from abroad.
Sort of like how some people can't qualify for a post-paid cellphone plan, but anyone can get a prepaid cellphone plan.
As it is, though, we can't block VPNs even if we wanted to; VPN companies are currently winning the arms race against VPN detection. (You can tell who's currently on the winning side this week by whether you see YouTube ads that make the claim that you can use a VPN to enable geo-shifting for Netflix. Netflix is legally obligated by its IP licence-agreements to do what it can to shut that down; and whenever they manage it, the VPN services stop making that claim for a while, until they figure out how to make it happen again. Currently, they're making it.)
Wow, you just keep swinging and missing with such confidence! I use VPNs because I don’t trust rando open WiFi hotspots or the ISPs that serve them. I frequently still buy things over the VPN and stay logged in with accounts attached to me.
You seem like the type of business owner that would remove the handicap accessible entrance because it’s easier to break into.
They are talking about *registration*, how often do you register new accounts?
I also believe all registration forms should outright ban non-ISP IPs.
But in your B2B use case you'll just say setup an office VPN proxy and make it look like your coming from the office ISP connection.
And I think you’re a privileged fascist who has never had to live with a hostile ISP.
So what? If our service gave you that clear error message that we don't accept VPNs — well, you would have the perfectly-viable option of just waiting until you get home to register. It's not the sort of service you register for "in anger" with any kind of urgency. It's a B2B data-analysis API, only relevant for companies and professionals; and it's one that you need to spend hours exploring and reading the docs of to get real use out of, because "real use" almost always consists of calling multiple endpoints, graph-walk-wise, to explore data relationships.
Also, as it happens, we don't consider "invited by a team member" to be a registration; coming in through an invite link doesn't go through any of the checks. (This is because we've yet to actually see a promotion-fraud attacker who has ever taken advantage of the teams system. Probably they assume all accounts in a team will be rate-limited together at the team level, even though we've never said anything to that effect.)
So if you're working for a company that has chosen to use our API, and you're not the one person in your company who was tasked with initially evaluating our API, but rather are just someone who needs to actually use it — then you'll do that by receiving an email, clicking on the magic link, and filling out your details; and all of that will work just fine over your VPN on the rando open WiFi hotspot. Because "clicking on an invite link" is distinguishable from promotion fraud.
It's only if your traffic is indistinguishable from promotion fraud — if it fits the signature of promotion fraud — that we'll block it. And that signature, right now, for us, is:
1. sends traffic from a colo, VPN, or Tor exit-node IP address;
2. uses an email address where the domain is either:
2a. from a "temporary inbox service";
2b. from one of a few common mail services which do not themselves speed-limit registrations (Microsoft / outlook.com is bad for this; Rambler.ru is another. Perhaps surprisingly to any cypherpunks in the audience, ProtonMail isn't in this set — so they're fingerprinting you somehow to enable that!):
2c. freshly-created (<2d old);
2d. has an MX record whose zone's NS record indicates that their MTA is hosted on a cheap colo (you'd think this would generate false positives, but it's very unlikely on the modern web, as an MTA on such a box would have too low a reputation to send mail, so nobody would bother unless the MTA is only for receiving, i.e. is a one-off temporary email proxy-host);
3. uses an email address where the username is either:
3a. "gibberish" — indistinguishable from keyboard-mashing (see https://pypi.org/project/gibberish-detector/);
3b. generated by combining census-data-list names with 4+-digit number suffixes, with the former to make the address look real, and the latter to ensure a low change of collision at time of address registration;
4. specifies a user name, organization name, and/or API-key label (all free-text fields) as either gibberish, or mail-merged repetitions of the name in the address. (Real people who don't want to fill these out say something petulant here, rather than keyboard-mashing.)
5. matches the browser fingerprint of a previously-detected multiple-incident attack. (We do client-side browser fingerprinting, only for the registration page, to catch people who use e.g. Puppeteer + Zyte Smart Proxy Manager to automate registrations; but who don't realize that the Puppeteer Stealth plugin exists. Which is, surprisingly, a lot of people.)
These are all just factors in your registration "credit score"; you have to trigger multiple of them to get denied by our accounts backend.
We only start putting IPs into blocklists (thus making it into, in a sense, a single-factor denial) once we've actually seen attacks coming from these IPs. But we do investigate each such attack; and if the offending IPs all came from some "dedicated-bare-metal unmetered-bandwidth machine host" that nobody's ever heard of + exists as its own ASN + has no claim on its website to be policing its customers for abusive behavior (or worse, doesn't even have a website!)... then it's time to block that entire netblock, and every other netblock owned by the ASN, and every other ASN owned by the company. Every time we haven't before, the attacks just come back.
Surely that is not a pleasant web browsing experience? How do you deal with the constant captchas or straight-up blocks against vps ip ranges?
Commercial vpn's for all their faults are treated much better than a diy setup on average.
For example, does "free-tier" provide an opportunity for the "API SaaS" operators to collect personal information, or at least email addresses, belonging to users who have no intent of paying the "API SaaS".
The notion of "fraudulent sign-ups" for something allegedly offered for "free" sounds funny. Fraud implies that the alleged perpetrator is obtaining something unlawfully or unfairly. However if that thing is "free" then how could this ever be true. Perhaps the operator of the "free" service actually is expecting to receive (or take) something from the user. When the user fails to provide or allow the operator to take this thing from her, then the operator complains of "fraud".
The problem with this reasoning is that it fails to account for value of the right to privacy.
Consider a telephone analogy, imagine a _toll-free_ number for free information. Imagine the operator referring to callers with unlisted numbers or ones who did not allow caller-ID when calling a toll-free number to obtain free information as comitting "fraud on the service".
As a user, I see no point in "free-tier services" that require "sign-up" because they are really not "free". The user is being asked to give up some of her rights in exchange for the "service".
Consider a public square analogy, imagine someone standing on a street corner handing out _free pamphlets_ but requiring people to "sign-up" to receive one. Then imagine the pamphlet publisher accusing those who did not provide real names and other details when "signing-up" as comitting "fraud".
If the operator ceases the "free-tier" tactics to gather data/information about users and simply sells paid service then this problem "fraud on our service" becomes moot. The question becomes why the operator feels it _must_ provide "free" service.
Consider a www analogy, imagine the "CTO" of HN accusing users who read HN but do not create accounts or provide their real names to HN as committing "fraud on our service".
The www provides an enormous amount of free information. Beyond purchasing service from an ISP, no other "sign-up" is required. Accusing www users of committing "fraud" for retrieving such information without "signing-up" is silly.
The majority of "fraud" occuring via the internet is not being perpetrated by users on "tech" companies. It's being perpetrated by "tech" companies on users.
So, technically, our revenue is entirely independent of customers. Which is why free-tier users still benefit us: the more DAU our platform receives, the more our partners value it, and the more they’re willing to pay us to make their data available through it.
And before you ask, no, we don’t give our customer data to our partners; all they get to know is DAU and API call count for their network.
> Whats the purpose of "free-tier" API SaaS.
Mostly? Giving people a taste without the friction of paying, so that they get hooked, and start paying later. Like how you can have one Heroku VM for free. Or how GCP gives you a free month of usage when you sign up.
I can’t think of a direct analogy within the API SaaS vertical specifically; but a hypothetical analogy would be if Twilio gave N free credits on each sign-up.
> Fraud implies that the alleged perpetrator is obtaining something unlawfully or unfairly. However if that thing is "free" then how could this ever be true.
Our free offer is intended to give people a certain amount of credits to spend to try out the service. By registering multiple accounts, you get multiples of that promotional amount. And, in fact, by registering multiple accounts, you escape the rate-limiting we place on every account, to ensure QoS and prevent Denial-of-Service attacks against our service. So we prevent people from registering multiple accounts.
Analogy: someone who sees a free sample display in a grocery store, and stuffs the entire display into their bag. And then camps out the display each day, taking the whole thing again the instant it gets restocked. While also going around to N other stores in the chain, camping them out as well.
It may not be illegal, but it’s 1. unethical, 2. against the spirit in which the promotion was intended, and 3. screws all the other customers out of their opportunity to get the free thing, because you’re using up their “share.”
My main bad actor problem was fraudulent credit cards but stripe took care of that.
Just like if you go to Costco and get free sample of a product, the staff won't let keep taking more and more and more free samples. That's exactly what free usage tiers are, free samples.
As it happens, this particular company does not have such a restriction in their terms. Maybe they should add one, e.g., an explicit prohibition against multiple free API keys assigned to the same user.
Using the physical retail analogy, there is no sign stating something like, "One sample per person. Thank you for you cooperation."
"Free usage tiers" are nothing like "free samples" in a retail setting. A potential retail customer does not _need_ to provide an IP address in order to take a sample. Costco does not track the behaviour of potential customers who take free samples. Nor is Costco providing "free" samples as bait in order to collect data on behalf of other entities. This particular "API SaaS" crypto/blockchain company collects aggregated data for other entities. Their "legal terms" also permit them to sell this data. According to the HN comment, it wants usage data from IP addresses issued by ISPs not auctions.
The "free tier" problem being articulated here with respect to IP addresses is not that there are "too many" potential customers, i.e., too many IP addresses accessing the "free" API, thereby denying some potential customers from obtaining their "free samples". The problem is that the data collector cannot distinguish whether particular IP addresses represent distinct ISP subscribers, and whether such persons may be using automation to avoid mouse clicking, touchscreen tapping or other burdensome interaction. The complaint is that the "tech" company's efforts to _collect data about computer users_ are not working.
"Tech" companies require people to "sign-up". The incorporated "tech" website gets something in return for the "free" service. API's can be rate-limited. Potential paying customers, or non-paying users, can easily be blocked from using the API. This can all be done remotely from a keyboard. The retailer offering free samples of physical goods without requiring any information cannot adjust the number of samples available to each potenital customer, and certainly not remotely from a keyboard.
As such, the "limited supply" argument falls short. The complaint here is that a "tech" company wants to collect data about computer users and monetise it, and this is difficult because IP addresses do not necessary represent distinct computer users with certain charactersistics, not that a retailer is "running out of free samples".
"Free usage tiers" are nothing like "free samples" in a retail setting. A potential retail customer does not _need_ to provide an IP address in order to take a sample. The retailer does not track the behaviour of potential customers who take free samples. Nor is it providing "free" samples as bait in order to collect data on behalf of other entities. This particular "API SaaS" crypto/blockchain company collects aggregated data for other entities. Their "legal terms" also permit them to sell this data. According to the HN comment, it wants usage data from IP addresses issued by ISPs not auctions.
The "free tier" problem being articulated here with respect to IP addresses is not that there are "too many" potential customers, i.e., too many IP addresses accessing the "free" API, thereby denying some potential customers from obtaining their "free samples". The problem is that the data collector cannot distinguish whether particular IP addresses represent distinct ISP subscribers, and whether such persons may be using automation to avoid mouse clicking, touchscreen tapping or other burdensome interaction. The complaint is that the "tech" company's efforts to _collect data about computer users_ are not working.
APIs can be rate-limited. IP addresses can be blocked. All with a few keystrokes. Users are granted _permission_ to use the "free" sample and that permission can be revoked. Retailers of physical goods have no such abilities. They generally cannot control how many samples a person takes, they generally cannot ban selected people from taking samples, and they certainly cannot do this with a few keystrokes. Generally, the physical retailer will have a finite suply of free samples. When one person takes a sample, that is one less sample available for someone else. Whereas when one person accesses data, it does not result in "less data" for another person to access. There is no such depletion.
As such, the "limited supply" argument falls short. The complaint here is that a "tech" company wants to collect data about computer users and monetise it, and this is difficult because IP addresses do not necessary represent distinct computer users with certain charactersistics, not that a retailer is "running out of free samples".
Maybe the closest thing would be an ASN reputation score, where one of the factors is the ASN’s newness, and another is the average recency of their acquisition of the IP blocks they own.
Some of the sketchiest ASNs I know of have been assigned for many years, and perfectly reputable ISPs have to acquire new IP space occasionally.
...which can be addressed perfectly fine with a static, human-audited blacklist, because the old bad actors don't change.
The goal of a reputation score would be to complement such a static blacklist, by recognizing the fly-by-night operations that constantly crop up and disappear for what they are; or, conversely, by rewarding the ASNs who manage to stick around long enough without ever doing anything to land them on the static blacklist.
In other words, just like how mail domain reputation works. If your domain sticks around long enough without ending up on a DNSRBL, then it builds up a positive reputation, which acts as a counterweight in spam-filtering algorithms. If you sell the domain, though, then its reputation resets.
> perfectly reputable ISPs have to acquire new IP space occasionally.
Yeah, but the average age "by volume" of all their IPs would still be pretty old, as the new acquisitions would be marginal compared to their existing holdings.
… only to find out that you’re through no fault of your own blocked by region because we suddenly have a splinternet in the great year of 2022
While my tool is just a proof of concept, it can easily be scaled up to run checks on a sign up form to prevent bad actors from abusing the system.
CGNAT requires buying IPs and a /22 is big enough for 100k customers. Your assumptions are wrong.
We find IP lists alone dont really cut it though. Its easy for someone to just tether to their phone to signup.
If your interested we would love to chat :)
Regarding the abuse, bots, etc. Yes, we have abuse cases, and you are partially right about that. However, we take every abuse case very seriously since we are responsible for hundreds of LIRs who brought their IPs to IPXO. If we ignore the abuse, we would not be boarding tens of thousands or hundreds of thousands of new IPv4 every week.
- Vincentas, CEO @ IPXO
I don’t know what’s a price that I feel would actually be too high. Doubling it to $100 still seems reasonable, but 200? $1000?
10 years ago they were worth $10 each, I wonder how much they’re worth in another decade.
For the more knowledgeable amongst us, how is this not an investment opportunity? What’s stopping a hedge fund from buying up a /12 block and renting it out?
This is basically what Amazon does.
I don’t see an easy way for a hedge fund to rent out the IP space unless they are a cloud provider. The problem is that to participate in BGP/the Internet, the smallest allocation that can advertised is a /24. You need to own the space you advertise before an ISP would allow this. The hedge fund would need to transfer the a minimum of a /24 to you and I guess you would have a contact to pay the hedge fund a monthly fee and give the space back when you’re done? Seems a bit messy to me.
Routers can only handle so many routes, so their operators set floor values for size of route they'll generally accept.
I'm not counting gold-plated routers because I see no reason to force ISPs to buy those.
A top end router today can handle ~million routes. You’re talking a four orders of magnitude increase.
Do we really want IP space carved up into smaller and smaller bites? Do we really want even more and smaller entities advertising routes into BGP? The big players have enough troubles with it - we don't need small businesses with a /28 playing in those waters.
There's a lot of value in owning your user-facing IPs and being able to move them around as needed, but a lot of services don't really have that many user facing IPs, so utilization is low if they get a /24 per location.
On the converse - I think of all the smaller businesses I worked around that really wanted to get their own portable IP block and ASN because they thought it made them serious ... but just had no business playing in that space.
Otherwise, just move to IPv6 or something and fix the problem in a saner way.
So if an ip isn't in the cache it'll go through a slow path instead and get cached.
Why this wouldn't be possible in hardware is beyond me.
Routing on commodity hardware is becoming a thing too with DPDK and OVS, you can now do 200gbps on a single x86 box.
Huge numbers of routes are simply not an issue these days, unless you have truly ancient crappy equipment (maybe it was second hand for example).
This is a solved problem these days.
I personally know of IPXO[0] and can vouch for them as being legitimate and well ran. If you have an idle /20 laying around or whatever, I highly suggest getting it on their market and making some relatively easy money leasing out your blocks.
The total interaction (short of initial setup) these days is clicking a few buttons in your favorite interface to publish ROA records every so often when an IP block sees churn. A hedge fund could hire a junior neteng to handle those requests, the very rare abuse complaint, and any hijacked routes you need to track down.
Overall this is becoming a mature market with a number of players emerging for a public market. In private it's been going on for some time on a much more informal basis.
[0] ipxo.com
These marketplaces are open to all and operate with the knowledge and blessing of the RIR's. However, the recipient does still need to justify the allocation they are buying just like when RIR's were handing out addresses directly.
While anyone with existing IP allocations are allowed to lease them out to anyone, even customers you are not directly providing connectivity to, IP's leased out to non-connected customers do not count towards justification for new allocations/transfers. This is different from Amazon or an ISP leasing IP's to their directly connected customers, which do qualify as justification towards further allocation/transfer justifications.
So a transfer would be denied by the RIR unless the recipient claimed they were going to directly use the /12 to provide internet service to themselves or customers. If they lied on the RIR application that would constitute fraud, which is one of the very few reasons RIR's will actively go and revoke a registration for. RIR's are aware that businesses and use cases can change over time and they explicitly do not revoke for simply not needing addresses anymore, to encourage a liquid and efficient resale market. So the question comes down to whether the application was in good faith at the time it was made. RIR's know what's up and it would be very unlikely for a hedge fund to pull this off without actually investing significant capital and effort to deploy an operational network that would justify a /12.
There have been proposals in ARIN to explicitly allow the leasing use case to count towards future justifications, or even for original allocations/transfers but these proposals have not gone anywhere.
The numbering authorities (APNIC, ARIN) will block the transfer if your justification for purchasing isn’t to actually use them yourself. It’s not an open market that anyone can purchase on.
Maybe not that much more. At some point the demand for ipv4 addresses is going to wither as ipv6 adaptation grows. 10 years ago we were at <1% ipv6 adaptation, now we're at 40%. Give it another decade and I can imagine someone like google or apple sunsetting ipv4 support completely and after that ipv4 addresses aren't going to be worth much anymore.
Sure, IPv4 blocks have reputation but I've never heard of the equivalent for ASNs, especially ones that have a small number of digits.
32-bit ASNs are very easy to come by from all registries and there are lots of them. Most all BGP implementations have supported them for a long time so there shouldn't be a reachability issue.
Am I missing something? Is this just plain vanity?
IPv4 blocks are actually useful. If you run a datacenter it makes sense that you'd try to get something bigger than a /24. Why you'd care about having a 4 digit ASN I don't understand... easier to remember?
There is an RFC to extend this to 4-byte for the ASN part but that is not widely supported yet.
https://community.cisco.com/t5/routing/how-to-set-up-in-the-...
https://datatracker.ietf.org/doc/rfc5668/
For small enterprises/end users (that might not define their own communities at all) this is usually not a problem but for larger networks or ISP's you end up with a compromise where you are truncating the 6-digit ASN or using a private ASN, neither of which are desirable. Arin let's you request a 2-byte ASN and if they have one in inventory (they usually do) you can get it.
I remember setting up BGP in 1998 for a local mega corp. They had 2 full T1s! I think there were only 50K routes.
tl/dr; ASN's are highly visible to network engineers, it's your identiy as a network. Lower/shorter numbers are "better", at least to some people.
All of the 4 digit ASN's were originally allocated in the 90's, during the initial ISP/dot com boom and are often viewed as a sign of being an established player, or just "cool". Almost all the major ISP's use 3 or 4-digit ASN's: 3356 = Level3/Centurylink/Lumen, 701 = Verizon, 174 = Cogent, 1299 = Telia (now Arelion), 2914 = NTT, 6453 = TATA, etc. Even Netflix snagged 2906 when ARIN suddenly recycled a bunch of 4-digit ASN's in 2009.
If you are an ISP, every one of your BGP customers and peers has to configure a BGP session with your ASN so it has maximal visibility in that use case. Even if you are just peering on public IX's, every peer will see your ASN when they configure the session or do "show bgp sum".
These days there is a similar effect though less dramatic for 5-digit ASN's, and that is reflected in the lower asking prices.
What surprises me is how fast the 5-digit ASN's were selling (look at recent sales). In the ARIN region you can get a 5-digit ASN just for asking when you apply, otherwise they assign a 6-digit by default most of the time. The takeaway from this is that people are paying for a definite, specific number that they like rather than take their chances with a random assignment from ARIN.
Sure, I can see 6939 or 701 and know instantly who that is, but in the end, it matters nothing for the other 98% of ASNs I don't recognize on sight and who they might be behind them.
Anybody that is paying money for a "vanity" ASN is just doing it for self-ego stroking. To the people doing the work, it doesn't matter one iota.
There were IPng proposals in which zero-padding an IPv4 address gave you a valid, interroutable IPng address. One network is a strict superset of the other.
It's been 22 years since the first Global Unicast IPv6 allocations were made and progress has been very slow. This will not be complete until long after I am retired.
How would you accomplish this? How could an IPv4-only system send a packet to an IPv8 address? IPv4 packets only have 32 bits for the destination and source IP addresses, there's no way to fit the address for any newer protocol with longer addresses in there.
Concretely: if you're a router and you accept IPv6 packets, you must offer NAT64 services on any interface from which you accept IPv4 packets. The upgrade ripples outward from the core routers (default-free zone) in two waves. As soon as all of a router's peers support IPv6, that router can drop NAT64 and IPv4. No flag days. All coordination is between a pair of peers with a direct link.
There were IPng proposals that had this requirement (using different terms, of course). IPv6 wasted more than a decade fighting against NAT64, tooth and nail. It wasn't until they finally caved and standardized NAT64 that people took IPv6 seriously -- but by then it was too late to make it a mandatory feature of dual-stack routers and there was already hardware shipping with IPv6. The clean upgrade path was lost forever.
Next time anybody complains about the IPv6 transition taking so long, you know who to blame.
NAT64 has worse scaling than CGNAT (requires more state and moving pieces) so it was never a solution to drive adoption.
Yeah, because NAT64 is 11 years old:
https://datatracker.ietf.org/doc/html/rfc6146
IPv6 was useless without it. It took over 13 years for people to figure that out.