An open market for buying and selling IPv4 Addresses is coming. Soon. As I wrote previously, IANA is running out of unallocated IPv4 addresses. Estimates vary, but by 2010 (or 2012 at the latest) the world will be out of unallocated IPv4 addresses.
Sometimes it is hard for the general public to understand what this might mean. Essentially, after 2010 or so, if you want to start a new company and get connected to the Internet or just are growing and have more devices that need to have IP addresses, things won't be the same as they are now. Right now what happens is that you go to ARIN, if you're in North America and document your need for IP addresses, you pay a modest administrative fee, and then they allocate them to you. If you grow and you need more, you document how you've used up the ones that you have, and they give you more of them.
All of this assumes that you want your own IP addresses that are not tied to any particular provider (this is an important point that we'll get back to). But even if you get your IP addresses from some provider, they have to get them from somewhere. If you want to be reachable from the Internet, you need an IP address—an IPv4 IP address in particular. And very shortly those are going to get much harder to get.
So let's talk about what happens after the IPv4 addresses are all "used up."
Once you can no longer just go get "new, never before used" IP addresses, you will have just a few options
- Stop growing (but growing is what keeps us alive)
- Assign private IP addresses (RFC1918) and use lots of NAT. This works reasonably well for consumer access systems, but terribly for hosting and most business uses and violates the end-to-end principle.
- Use IPv6 (but it's not very useful if you actually wanted to be on the Internet rather than some other network). This is roughly equivalent to using lots of NAT.
- Buy a company that has IP addresses (huge transactional cost for marginal value)
- Buy IP addresses on the black market
Of those options #5 looks like the best/cheapest/most effective for many uses. Private addresses, option #2, are completely reasonable for lots of uses. But it does not provide addresses that are directly reachable from the Internet. It's nice to think about #3, using IPv6. One day, perhaps, there will be scalable ways to get to the Internet from IPv6-addressed computers and there will be a tiny bit of actual content on the IPv6 Internet to get to natively. But until then, most people will want to put their eggs in the actual Internet basket. Of the remaining options, #1 is a non-starter for businesses and #4 is expensive and complicated. So then most people will want to buy some lightly used IPv4 addresses—the kind that an elderly woman only used for checking email once a week on Sundays.
The three major downsides of buying IP addresses are:
- Buying address blocks is a violation of the terms of service of every Regional Internet Registry (RIR) at the moment
- It is difficult to determine whether the person offering an address block has a right to sell it
- It is extremely difficult to determine just what condition the address block is in.
But #2 and #3 are more interesting. These are essentially "title search" and "home inspection," to use the analogy to the house-purchasing process. When someone buys the right to use some IP addresses, they will want to know the ownership and use history of those addresses. In particular, they will want to know who has "owned" (been allocated) the IP address, to whom else it has been sub-allocated (customers who may have used it), and what they have been using it for.
The reason for this is simple: if an address block has been used by disreputable parties for disreputable purposes, it will find itself in blacklists around the Internet. People like Spamhaus may have the addresses listed on one of their known spamming lists, or worse yet, on the DROP—Don't Route or Peer list. There may be other, less obvious, ways to indicate that an address block has been used for nefarious purposes. These include looking at the origination and transit history for the prefix to see if it has routinely been located in known bad "neighborhoods" on the Internet. In any of these cases, the addresses are dramatically less valuable than a fresh prefix would be.
The RIRs can provide some basic titling information for IP address allocations but they are not really set up to provide more information about who, historically, has routed a particular prefix and what they have done with it. Without a service like this, it's hard to see how a transparent and fair market for IPv4 addresses will develop. Everyone offering an address block will be like a used car salesguy, trying to hide the Katrina mud under the carpets of a poorly-refurbished junker.
And there's an important distinction that was alluded to previously: There is a huge difference between an IP address that can only be used with a single provider and one that is owned by the end-user and can be announced as a globally routable and portable prefix. Control (almost "ownership") of the prefix conveys huge advantages to the end user—these are advantages in price-negotiation with providers, control, administrative overhead (not having to ever re-number), etc. These prefixes are clearly going to be valuable in any market for IP addresses, because they have real-world value to end-users. Once they can no longer be obtained from the RIRs, companies will be willing to buy them wherever they can.
It will be extremely interesting to see how this market develops and how the associated information services ("title search" and "prefix inspection") develop. My colleague Jim Cowie has developed some very interesting (and in-house, for the moment) data products to look at the historical behavior of prefixes and the implication of that behavior for future use. It will be interesting to see if those data products turn out to be useful in this, or related, applications.
Nice write-up Todd. In addition, may I comment that the current proposal in the RIPE region has moved into last call and is likely to pass consensus this year and will be implemented immediately afterward.
A similar proposal in the ARIN region has just been abandoned, leaving a proposal for 'emergency transfers' on the table. I would encourage the ARIN community to support this proposal and adopt it quickly. Discussing this for much longer will drive the time to implement beyond the point of the actual depletion and leave us in a limbo. An imperfect policy is better than no policy at all.
For the sake of completeness, Geoff Huston is currently also pushing a transfer policy proposal in the APNIC region but so far it's not being accepted by the community.
There are no similar proposals in the LACNIC and AfriNIC regions that I'm aware of, so transfer policy is unlikely to become a formal 'global policy'. Let's just hope that we're at least able to coordinate the transfer policies in regions that do implement them, to prevent people from shopping around.
I believe that it's past time to look at Vince Fuller's proposal for opening up the former Class E space; this will require stack changes on endpoints and infrastructure, but those are coming, anyways, and even with this requirement, it's still a useful thing to accomplish, IMHO.
Roland,
While I also think that taking a hard look at Class E space is very tempting, turning that into globally usable unicast space is a pipe dream. At the current consumption rate it gives us something like 1 year of extra space while at the same time requiring every router on the Internet to be upgraded, quite possibly also in hardware. If we're going to go through that effort we might as well just all adopt IPv6 and be done with it.
That said, I would encourage and support any proposal that would turn Class E into RFC1918-on-steroids unicast space to be used in walled garden environments such as NGNs, where all the nodes are under some form of single control anyway. 256 million IPv4 addresses ought to be enough for any private network :-)
This would put an enormous relief on the pressure on global unicast v4 space, IMHO.
The use of DNS SRV records for HTTP would expand the available 'address space' of a web hosting environment by four orders of magnitude without requiring any new IP address allocation. That extra 'space' is available right now but without SRV you'll get pushback from companies that don't want to advertise their URL as 'www.coolcompany.com:23481'.
Gary, the use of virtual hosting (the Host header in HTTP) already enables an unlimited number of web sites to be hosted at one IP address. How is the use of SRV records an improvement on this system?
What about all the corporations like GE, Ford etc who have entire class A ranges of 16 million IP addresses, allocated in the 1980s when nobody had any idea the internet would become what it has.
Could the IANA, RIPE or ARIN force or encourage these companies to surrender their address spaces for the greater good? Maybe we need a government bailout scheme to buy back our IP addresses to save the internet ;)
OrgName: AT&T Global Network Services NetRange: 32.0.0.0 - 32.255.255.255
OrgName: African Network Information Center NetRange: 41.0.0.0 - 41.255.255.255
OrgName: Amateur Radio Digital Communications NetRange: 44.0.0.0 - 44.255.255.255
OrgName: Apple Computer, Inc. NetRange: 17.0.0.0 - 17.255.255.255
OrgName: Asia Pacific Network Information Centre NetRange: 43.0.0.0 - 43.255.255.255
OrgName: Asia Pacific Network Information Centre NetRange: 58.0.0.0 - 58.255.255.255
OrgName: Bell-Northern Research NetRange: 47.0.0.0 - 47.255.255.255
OrgName: Computer Sciences Corporation NetRange: 20.0.0.0 - 20.255.255.255
OrgName: Computer Sciences Corporation NetRange: 20.0.0.0 - 20.255.255.255
OrgName: Department of Social Security of UK NetRange: 51.0.0.0 - 51.255.255.255
OrgName: E.I. du Pont de Nemours and Co., Inc. NetRange: 52.0.0.0 - 52.255.255.255
OrgName: Eli Lilly and Company NetRange: 40.0.0.0 - 40.255.255.255
OrgName: Eli Lilly and Company NetRange: 40.0.0.0 - 40.255.255.255
OrgName: Ford Motor Company NetRange: 19.0.0.0 - 19.255.255.255
OrgName: General Electric Company NetRange: 3.0.0.0 - 3.255.255.255
OrgName: Halliburton Company NetRange: 34.0.0.0 - 34.255.255.255
OrgName: Headquarters, USAISC NetRange: 55.0.0.0 - 55.255.255.255
OrgName: Headquarters, USAISC NetRange: 6.0.0.0 - 6.255.255.255
OrgName: Hewlett-Packard Company NetRange: 15.0.0.0 - 15.255.255.255
OrgName: Hewlett-Packard Company NetRange: 16.0.0.0 - 16.255.255.255
OrgName: IBM Corporation NetRange: 9.0.0.0 - 9.255.255.255
OrgName: Interop Show Network NetRange: 45.0.0.0 - 45.255.255.255
OrgName: Japan Inet remarks: NetRange: 43.0.0.0 - 43.255.255.255
OrgName: Level 3 Communications, Inc. NetRange: 4.0.0.0 - 4.255.255.255
OrgName: Level 3 Communications, Inc. NetRange: 8.0.0.0 - 8.255.255.255
OrgName: Massachusetts Institute of Technology NetRange: 18.0.0.0 - 18.255.255.255
OrgName: Merck and Co., Inc. NetRange: 54.0.0.0 - 54.255.255.255
OrgName: Merit Network Inc. NetRange: 35.0.0.0 - 35.255.255.255
OrgName: Performance Systems International Inc. NetRange: 38.0.0.0 - 38.255.255.255
OrgName: SITA-Societe Internationale de Telecommunications Aeronautiques NetRange: 57.0.0.0 - 57.255.255.255
OrgName: The Prudential Insurance Company of America NetRange: 48.0.0.0 - 48.255.255.255
OrgName: United States Postal Service. NetRange: 56.0.0.0 - 56.255.255.255
OrgName: Xerox Corporation NetRange: 13.0.0.0 - 13.255.255.255
OrgName: cap debis ccs NetRange: 53.0.0.0 - 53.255.255.255
I don't understand how you can dismiss IPv6 so quickly. It is the correct way to solve the problem. On top of that, every operating system I can think of has supported it for atleast 10 years. Remember Windows 2000 ships with IPv6 support. When IPv4 addresses run out, ISPs start flogging ipv6 addresses to end points instead.
You can't have more than one SSL website on a particular IP address because the encryption tunnel is constructed prior to the HTTP Host header arriving. So the increasing use of encryption means a lower density of website/ip address multiplexing. I realize there is some work on revamping the protocol to all HTTP headers to arrive unencrypted (TLS upgrade).
You also can't have an infinite number of web sites on a single endpoint due to hardware constraints, redundancy goals. Using SRV records allows your normal routing hardware to multiplex IP streams to multiple endpoints rather than introducing a NAT/TCP proxy device into your infrastructure to forward HTTP requests to multiple endpoints.
I'm not suggesting that SRV records solve the problem, they don't even come close, but I think it might help in some particularly common situations.
The bigger problem with this is that lots of people have outbound filters that limit outgoing traffic to port 80, 443, and secure email ports. Not sure how to change that policy situation.
The IP address situation is a real mess without any 'good' solutions at the moment. Running out of addresses is only one of the problems. Maintaining a stable global routing infrastructure and implementing better security and trust mechanisms are others (spam, DDOS, botnets,...)
philluminati: IPV6 has its own problems that are unrelated to address space. In particular an IPV6 only host will be invisible to an IPV4 only host. This means that in order to transition from IPV4 to IPV6 at the global-Internet level you basically need to dual-stack everything before you can start retiring IPV4 addresses. If I run an IPv6 only server I've got no clients. If I run an IPv6 only client, I've got no servers.
IPv6 also presents challenges to the routing community, which is already having problems with stable/secure default-free routing with the IPv4 address space.
@Gary: i'm pretty s that SNI will be deployed before an SRV jhck. It's in at least the non Microsoft browsers now and pretty well vetted. As for failover, that's such a mature technology now that I have trouble seeing it as a compelling for such an invasive change.
I don't understand this one from RIPE, why don't they approve IPv6-PI first before approving this one ?
Gary/philluminati: really, there are loads of people which are now behind IPv4-NAT which should have had an IPv6-address-block and be behind a IPv4-NAT of there provider for ages and only request an IPv4-address if they really think they need it (games or something ?)
@Gary and @chris adams:
Do not fight: there are actually *two* ways to have several TLS
certificates for one IP address.
The one mentioned by Gary is STARTTLS (RFC 2817), implemented
(server-side) for Apache by mod_ssl (Apache >= 2.2) and may be
others. But I'm not sure there is a lot of browser support. It is
still a TODO for Firefox
https://wiki.mozilla.org/Firefox/Feature_Brainstorming:Security
The one mentioned by Chris is "Server Name Indication" (RFC 4366,
section 3.1) which is an extension of TLS, supported for instance by
GnuTLS
http://www.outoforder.cc/projects/apache/mod_gnutls/docs/#sni-example
Glen
for your information African Network Information Center is AfriNIC which is one of the 5 RIR's and not a legacy holder as you put in your list
OrgName: African Network Information Center NetRange: 41.0.0.0 - 41.255.255.255