Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This seems to be a problem that markets will solve pretty well: as the resource gets scarcer, the price will go up, meaning people will have an incentive to use it more efficiently (selling unused address space), and/or look for alternatives (IPv6).


The major cost of IPs is routing table bloat. Every time I announce a new block, every router on the internet (that carries a full table) needs more (very expensive) memory.

The size of the routing table has been growing faster than the cost of fast router memory has been falling for some time now.

I mean, if you are only pushing a gigabit of traffic (and /maybe/ 10 gigabits, especially if the packets are large.) it's not that big of a deal; you can use dram and CPUs with large caches, and it's fast enough. But if you own a real pipe and have to push 40 gigs, or really, even 10gigs of small packets, my pair of vyatta routers on Xeons just isn't going to cut the mustard.

It's kind of a 'tragedy of the commons' because when I buy IPs, that money goes to ARIN (or to the previous owner of those IPs) - none of that money goes to all the router owners who have to pay for more fast router memory - even though I'm costing those people money.

The problem with runout intersects with this. If I need, say, 4000 IPs, I can get one /20, and occupy only one routing slot, or I can get 16 /24s and occupy 16 routing slots. From my point of view, from the point of view of the person who owns the IPs, there really isn't much difference between one /20 and 16 /24s. But the rest of the internet has to pay 16x as much if I get 16 /24s.


So with a few rules, you can design a market that works pretty well:

http://www.hbs.edu/faculty/Publication%20Files/09-091_0077c0...


eh, they are aware of the problem, but their solutions are still centralized ones; either preventing de-aggregation altogether, or making the end-user justify the usage, presumably to some central authority.

I mean, it might work out okay; that's pretty much what ARIN does now. I'm just saying, it's not exactly a market-based solution; that document proposes a market in IP addresses, but it largely leaves the routing table as a commons, even if it does propose to regulate that commons in ways that are similar to the way it is being regulated now.


Like I said: markets are not perfect, but what are the alternatives? I think it'll mostly work out ok: as prices go up, it'll push people to get serious about IPv6 and other alternatives.


My point is that the most important resources (routing table slots) are still allocated via informal central planning in your proposed scheme. And that isn't unreasonable; usually if you want a functional market, you need /something/ dealing with the externalities.

In the general case, sure, I like markets, too. It's just that markets deal very poorly with externalities, and I want to make the point that the way most people want to set up a market for IPs, routing table slots are externalities.

There is currently a process for selling IP addresses:

https://www.arin.net/resources/transfers/index.html

My understanding is that you give the previous owner enough money to make them happy, then you satisfy the requirements that you would have had to satisfy to get ARIN to give you the resources if you were requesting said resources from ARIN directly.


Not really; there's a mismatch between the people who incur the cost of getting IP address space, the content providers, and the people who would incur the biggest costs switching to IPv6, the connectivity providers.


Markets are usually not perfect, but tend to work decently even under imperfect conditions.

Edit: it's kind of mind boggling that people on a site about startups are so anti-market. Lord knows they don't solve all the world's problems, and all of us can think of examples where they don't work, but they generally work pretty well, and I don't see evidence that this is not the case here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: