IPv4 Address Auctions(auctions.ipv4.global)
auctions.ipv4.global
IPv4 Address Auctions
https://auctions.ipv4.global/
108 comments
> VPS IP? Bot.
> 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...
> 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...
If there was a list of commercial VPN provider IP ranges, we’d block that too.
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.
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.
> 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
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.
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.
> I frequently still buy things over the VPN and stay logged in with accounts attached to me.
They are talking about *registration*, how often do you register new accounts?
I also believe all registration forms should outright ban non-ISP IPs.
They are talking about *registration*, how often do you register new accounts?
I also believe all registration forms should outright ban non-ISP IPs.
> also believe all registration forms should outright ban non-ISP IPs.
And I think you’re a privileged fascist who has never had to live with a hostile ISP.
And I think you’re a privileged fascist who has never had to live with a hostile ISP.
This links the account to where you sleep at night. No thanks.
Well if your IP address is that much of a security risk for you, then I hope you have the discipline to never visit anything without vpns/proxychains.
So would your credit card, even more closely. Guessing that means you never buy anything online?
No your credit card does not. Your credit card can show one of your office address for example and be very legit. You can possibly losing some very wealthy customers, or customers who are victims of domestic violence. They don't want their sleeping address in a database because of crazy fans, stalkers and more. Many addresses in various services are very likely to eventually be sold by some ad tech / marketing company one day, where for the low price of $1-$50 you can get all the info you want about people.
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.
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.
> 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.
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.
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.
Protonmail does not allow VPN only registrations I think without payment?
Have you ever considered that some people use vpn in order to be able access your service not because they want to hide from you?
Yes. Despite wanting to, those people will also be unable to ever pay for our service, because — amongst other reasons — our service is hosted on Google Cloud; and Google has decided to block people in countries which the US trade-embargoes, from interacting with any Google servers — including Google Cloud customer servers. It's a whole thing. We'd have to go multi-cloud to get around it. (AWS solved this by building an AWS China region that's actually owned-and-operated by Chinese companies without Amazon leadership.)
That's a big assumption that they won't be able to pay you. It may be economically true enough that you don't care, but "unable to ever pay for our service" is not a given. My physical location or current internet connection does not determine where my payment method exists.
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.
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.
If it was practical to do so (maybe involving a clever splitting of customer dashboard pages onto different domains in different Cloudflare zones?), we would only shut off free-tier access for these people, while still allowing sign-ups that skip the promotion and take (and place a hold on) a card straight from the start.
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.)
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.)
They make it work via renting people's bandwidth at homes, so their connections source from residential ISP IPs. https://arstechnica.com/gadgets/2021/08/netflix-is-adding-re...
Russians can access Google Cloud fine.
Tangent, but the US sanctions against Russia consist of a series of specific sanctions (https://www.trade.gov/country-commercial-guides/russia-sanct...) rather than a general embargo on trade. Mostly they're an import ban (because Russia relies on global exports to acquire USD), plus a very narrow "luxury goods" export ban (which I believe is intended to annoy Russian oligarchs while not impacting most Russian citizens.) There's no current US sanction against export of technology or services to Russia; and so Google isn't legally obligated to do anything about Russian traffic.
That's actually incorrect.
I can't pay in Google play by any means. It's problematic to buy Windows license. Our company was banned from using Office 365 and our sharepoints shares was *wiped* up. Latter was happened, because we are connected to oil industry, and happened despite that we are buying office 365 using non-russia-based company.
Yes, but we can't pay using russia-issued Visa or Mastercard for foreign services.
Just curious which cloud based software as a service subscriptions have you purchase and actively maintain? Also approximately how many $ a year to you spend on those services? I’m curious because blocking IPs from bad actors is often the most effective and immediate solution to protect a service from a bad actor… it would be nice to understand the financial impact of this.
> for more than a decade
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.
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.
I am here to answer your prayers: https://rasbora.dev/blog/detecting-residential-proxy-network...
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.
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.
Interesting. "Anti-scalping" is a novel keyword to me; I've always just seen these kinds of techinques discussed under the "anti promotion-fraud" banner. Time for more research!
I guess similar reasoning caused cilium.io blocking Kazakhstani traffic. Never heard of this country? Bot. Thankfully they didn’t manage to block VPS and I still can use my VPN to circumvent the blocking. As if it isn’t enough for my government to block websites.
Worth noting that most IP blocks are going to be transferrable in some form, and thus most IP blocks can be sold on this site. IPXO is of course different since it's temporary leasing, but you couldn't really build a list of IPs that could be transferred, or you'd block most of the internet.
That’s what I figured was at the root of there not already being a DNSRBL-alike list of these IP ranges, yeah.
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.
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.
I don't think you have a good sense of what actually plays into IP reputation.
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.
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.
> Some of the sketchiest ASNs I know of have been assigned for many years
...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.
...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.
> solution is always to switch back to their real computer's web browser for anything requiring IP reputation
… 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
… 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
Whats the purpose of "free-tier" API SaaS.
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.
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.
In our specific case, we’re providing users query access to datasets supplied to us by channel partners; where these partners pay us to make this data available through our API, because it makes their own ecosystems more valuable for our service to be offered as a part of them.
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.”
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.”
[deleted]
I stopped reading a few paragraphs in. "Free service" does not mean without conditions/limitations. Signing up for multiple accounts when the T&C's say you only get one per person is fraudulent. Especially when they're trying to get around actually paying for the service you are using.
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.
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.
"Signing up for multiple accounts when the T&C's say you only get one per person."
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".
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".
From a personal experience charging $9 yearly for a basic tier kept away a lot of bad actors but didn't really drive away users because it's so cheap.
My main bad actor problem was fraudulent credit cards but stripe took care of that.
My main bad actor problem was fraudulent credit cards but stripe took care of that.
As it happens, this particular company does not include a restriction in their terms and conditions that explicitly prohibits the same user from receiving multiple free API keys. Using a physical retail store 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. 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".
"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".
Hmmm, those services selling you residential IP address proxying have become pretty cheap and easy to use. I guess if you'd block all those non-ISP addresses people would just start to use them. Im using one for a personal scraping project and it's very simple to set up, most allow you to pick a country of origin and other nice features.
Those are entirely wrong assumptions you have stated in your comment. IPXO works with many well-known telcos and infrastructure providers. Many projects use the IPs from the IPXO platform and announce them on AWS, Azure, or Google Cloud (those are actual SaaS companies) and not to mention Cloudflare, where we see IPs brought to their network using CF's BYOIP. All that information is visible and available on the BGP table.
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
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’m one of the people who uses cloud workstations sometimes. Lots of places ban you from doing stuff. Even Minecraft lol
Hi, At [Upollo](1) we do a lot for detecting dodgy signups and helping users to convert. IP lists are a part of what we use and we are planning on making our IP API's public in the near future.
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 :)
[1] https://upollo.ai
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 :)
[1] https://upollo.ai
Back when I had a leased line the outgoing IP was resolving to a colo facility right next to the dedicated servers they also offered. I'm glad I haven't and will never have a need for your company's services.
It's fortunate if the ISP already has enough IPv4 addresses even for CGNAT. Probably it's not the case for ISP in developing country.
> or CGNAT, than solve them for only the next 1024 customers
CGNAT requires buying IPs and a /22 is big enough for 100k customers. Your assumptions are wrong.
CGNAT requires buying IPs and a /22 is big enough for 100k customers. Your assumptions are wrong.
So much for running a personal VPN in the cloud.
It gets worse every year. I use a personal VPN, especially when travelling.
$50/ip is surprisingly cheap. 1,000 IPs will cost 50k, less than the cost for hiring a dev for half a year. An entire /16 block is still in the single digit millions.
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?
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?
> 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.
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.
> I don’t see an easy way for a hedge fund to rent out the IP space unless they are a cloud provider.
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
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
[deleted]
Actually, you can assign (not transfer) IP ranges and the one advertising it does not need to own it, but would need a Letter of Authorization (LoA) or similar.
What causes the restriction of /24, rather than being able to route individual addresses?
Physics.
Routers can only handle so many routes, so their operators set floor values for size of route they'll generally accept.
Routers can only handle so many routes, so their operators set floor values for size of route they'll generally accept.
Then it's time for operators to get with the times, because routers today don't have those same limitations as before.
Recent routers can handle 1M routes while the Internet routing table currently has... 928K routes. Allowing people to disaggregate further would blow out routers.
I'm not counting gold-plated routers because I see no reason to force ISPs to buy those.
I'm not counting gold-plated routers because I see no reason to force ISPs to buy those.
Nothing to do with with operators. Again, physics, notably tcam https://en.wikipedia.org/wiki/Content-addressable_memory#Ter...
very expensive.
TCAMs as shown in that page haven’t been used for a very very long time. Even in basic switches now the solution is ‘algorithmic TCAM’ (ie. something like hashtables or tries).
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).
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).
It seems that Cisco distinguishes TCAM and Hash at least. https://quickview.cloudapps.cisco.com/quickview/bug/CSCvg602... https://www.cisco.com/c/en/us/support/docs/switches/catalyst...
The documentation there is wrong/misleading.
Do you have any conception of how much TCAM would be required to individually route 14 billion IP addresses? And even beyond that what else would be involved to route things fast enough at that granularity.
A top end router today can handle ~million routes. You’re talking a four orders of magnitude increase.
A top end router today can handle ~million routes. You’re talking a four orders of magnitude increase.
I'm Linux there's a thing called route cache, which is really fast. Because in reality, even if you're a router at an IX you won't see traffic to all billions of ips.
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.
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.
Who said the prefixes had to go to /32? Just to /28 would only need 16 million routes.
I'm sure if you start a fund to pay those operators to care, they'll get right on it. The current case is the people who need much more granular space are different than the people who'd bear the cost of it.
Otherwise, just move to IPv6 or something and fix the problem in a saner way.
Otherwise, just move to IPv6 or something and fix the problem in a saner way.
Practical reasons of replacing "all the routers" aside ... would this even be desirable?
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.
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.
Kind of / maybe. At my last job, we wanted to host our own anycast nameservers. You get the best results from having four nameservers in DNS, and you want them independent, so there's four /24s out there doing not much other than DNS (I think there may be some other stuff now). On the other hand, some other changes meant our thousands of servers no longer had their own ipv4 addresses, so there's several /24s returned to the hosting provider to be used by others.
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.
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.
I tend to think the amount of companies who want to do that AND could do it well is vanishingly low.
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.
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.
Getting with the times these days means adopting ipv6, not putting more bandaids to ipv4
Routing tables need to be limited in size in order for hardware to decide where to route packets fast enough. In the past hardware was more cpu and memory bound than the present.
But also at present, dealing with millions of routes at the packet-switching level gets difficult. Especially because the speed of links has increased so much.
> What’s stopping a hedge fund from buying up a /12 block and renting it out?
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.
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.
> 10 years ago they were worth $10 each, I wonder how much they’re worth in another decade.
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.
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.
For $50 I kinda wish I could buy my own (/32) IP. I realize it’s horrible for privacy, DDOS-ing, etc. but there’s something neat about owning a specific address. Last place I worked at had extensive subnets and memorized IPs so that might be why.
RIRs won't approve transfers that are purely speculative. Also, IP leasing seems to mostly be used by spammers or other bad actors who trash the reputation of any IPs they use.
> 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?
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.
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.
I always figured that 4-digit and 5-digit ASNs were "cool" to a certain crowd but seeing them at the bottom of this auction page just seems like lunacy.
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?
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?
> Sure, IPv4 blocks have reputation but I've never heard of the equivalent for ASNs, especially ones that have a small number of digits.
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.
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.
As someone that does run an ISP and helps run an IXP, it matters nothing to me if somebody has a 32-bit ASN vs a 16-bit ASN.
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.
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.
> Sure, IPv4 blocks have reputation
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?
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?
Because BGP doesn't support ASN numbers larger than 16 bits; the 32-bit support is a pretty nasty hack, and for a long time, lots of equipment would not support it.
Running BGP with 4-byte ASN's is well supported by all major vendors by now. The issue is policies that use ASN:XXXXX communities which is 2-byte:2-byte.
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.
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.
32-bit ASNs have been a thing for close to 15 years now. Any older equipment likely wouldn't be able to handle a full routing table anyway.
I remember setting up BGP in 1998 for a local mega corp. They had 2 full T1s! I think there were only 50K routes.
I remember setting up BGP in 1998 for a local mega corp. They had 2 full T1s! I think there were only 50K routes.
NANOG had a panel on this a few months ago, "Buying and Selling IPv4 Addresses":
* https://www.youtube.com/watch?v=8FlTJEct9_s
* https://www.youtube.com/watch?v=8FlTJEct9_s
As the Internet is moving to IPv6 (https://www.google.com/intl/en/ipv6/statistics.html), soon these IPv4 addresses will be worthless.
The way to make IPv6 take off is to make IPv4 addresses astronomically expensive.
It's kind of funny that doing so would have been easy years ago; but the easier it is to just transition to IPv6, the harder it is to drive up the price of IPv4, as decreasing supply of IPv4 at this point will just drive down demand. Yes, you're "making IPv6 take off" in some sense by doing so, but not in a positive-feedback loop; more in a negative feedback-loop, where the market ends up in a new equilibrium state where nobody is switching.
Which is exactly why IPv6 never should have required transitioning off of anything.
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.
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.
Greenfield redesign was a great idea, until the ipv4 fire NATion attacked ...
> As the Internet is moving to IPv6
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.
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.
Been hearing that for decades now. Pretty sure they'll be valuable for a few more decades at the very least.
Just 1 decade ago usage was less than 1 percent, now it's nearly half. I'm not sure I'd bet decades more on them being particularly valuable when they haven't even been considered valuable for multiple decades yet.
> Just 1 decade ago usage was less than 1 percent
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.
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.
With that in mind the value of ipv4s would be worth tracking
IPv6 is not backward compatible with IPv4.
That's why ipv6 - will never work.
There must be new IPv8 with backward compatibility with ipv4 and easy migration to new proto without any changes in configs.
> There must be new IPv8 with backward compatibility with ipv4
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.
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.
Mandatory NAT64 support in every dual-stack router.
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.
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.
Funny that you think NAT64 is relevant. Every successful deployment I’ve worked with in the US is just dual stack. Native v6 networks with nat64 came after the big content providers got ipv6 server support for the dual stackers.
NAT64 has worse scaling than CGNAT (requires more state and moving pieces) so it was never a solution to drive adoption.
NAT64 has worse scaling than CGNAT (requires more state and moving pieces) so it was never a solution to drive adoption.
Nearly all IPv6 traffic is cell phones. And they are all behind NATs.
You got confused. If it’s ipv6 traffic it’s not behind 6to4 nat. Any stats about ipv6 on the internet are by definition not included stuff that got hit with 6to4.
What you describe is literally impossible. The ship has sailed and IPv6 usage is going up each and every year. Some countries, like the US, France, Germany, are at over 50% adoption.
I have been following the price history for some time now. It makes me really wish that I bought a subnet when it was $10 per IP as some kind of alternative investment. The ARIN maintenance fees seemed pretty high though.
I have a /24 I registered back in the 90's. There's no maintenance fee because it's a legacy block.
IIRC there's no way to use RPKI with legacy blocks; ARIN has been using this as a lever to get people to sign an LRSA. Has that been a problem for you? Do you expect it to become one?
It hasn't been a problem so far. The majority of Internet routes still don't use RPKI. I'd sign an LRSA if I really need to, but until that time...
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.)