[HN Gopher] IPv4 Address Auctions
___________________________________________________________________
IPv4 Address Auctions
Author : gmays
Score : 44 points
Date : 2022-08-10 17:59 UTC (3 days ago)
(HTM) web link (auctions.ipv4.global)
(TXT) w3m dump (auctions.ipv4.global)
| lysergia wrote:
| e63f67dd-065b wrote:
| $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?
| Bluecobra wrote:
| > 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.
| phil21 wrote:
| > 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
| [deleted]
| GoOnThenDoTell wrote:
| What causes the restriction of /24, rather than being able to
| route individual addresses?
| casylum wrote:
| 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.
| Dylan16807 wrote:
| 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.
| ikiris wrote:
| Physics.
|
| Routers can only handle so many routes, so their operators
| set floor values for size of route they'll generally
| accept.
| netr0ute wrote:
| Then it's time for operators to get with the times,
| because routers today don't have those same limitations
| as before.
| betaby wrote:
| Nothing to do with with operators. Again, physics,
| notably tcam https://en.wikipedia.org/wiki/Content-
| addressable_memory#Ter... very expensive.
| msbarnett wrote:
| 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.
| netr0ute wrote:
| Who said the prefixes had to go to /32? Just to /28 would
| only need 16 million routes.
| wmf wrote:
| 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.
| jleahy wrote:
| 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).
| tomklein wrote:
| 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.
| wmf wrote:
| 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.
| kloch wrote:
| > 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.
| Bluecobra wrote:
| 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.
| Prolixium wrote:
| 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?
| kloch wrote:
| > 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.
| mrweasel wrote:
| > 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?
| Sesse__ wrote:
| 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.
| kloch wrote:
| 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.
| pkrumins wrote:
| As the Internet is moving to IPv6
| (https://www.google.com/intl/en/ipv6/statistics.html), soon these
| IPv4 addresses will be worthless.
| bombcar wrote:
| The way to make IPv6 take off is to make IPv4 addresses
| astronomically expensive.
| derefr wrote:
| 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.
| zeristor wrote:
| With that in mind the value of ipv4s would be worth tracking
| kloch wrote:
| > 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.
| derefr wrote:
| As the CTO of an API SaaS who sees a lot of promotion fraud on
| our service (i.e. bots attempting to sign up for thousands of
| free-tier accounts, because enough free-tier API-keys lashed
| together [?] the capabilities of one paid-tier account), I see
| fraudulent sign-ups coming from IP addresses reallocated by these
| auction providers all the time. Addresses sold on IPXO
| (https://www.ipxo.com/) are seemingly especially bad for this.
|
| 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.)
| 1vuio0pswjnm7 wrote:
| 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.
| derefr wrote:
| 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."
| leach wrote:
| I'm one of the people who uses cloud workstations sometimes.
| Lots of places ban you from doing stuff. Even Minecraft lol
| hnov wrote:
| So much for running a personal VPN in the cloud.
| jimmydorry wrote:
| It gets worse every year. I use a personal VPN, especially
| when travelling.
| iancarroll wrote:
| 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.
| derefr wrote:
| 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.
| 5e92cb50239222b wrote:
| > 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...
| taf2 wrote:
| 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.
| derefr wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-13 23:01 UTC)