IANA, ARIN, and the IPv4 run-out (Series - Part III of IV)

Posted by Michael H. Warfield on December 08, 2010 at 9:05 AM EST.

Failure of IPv4 Address Reuse and Recovery

A topic that invariably comes up in discussions over the IPv4 address run-out centers around the idea that maybe we should just recover and reuse all the unused address space which has been allocated but which is no longer in use or never allocated in the first place, including some of the "legacy" space which was allocated before the advent of the regional registries.  Unfortunately it proves to be insufficient to address the problems with IPv4 and would even make some problems worse.

Back in the early pre-commercial days of the Internet the allocations and assignments were not governed by organizations such as IANA and the RIRs. At one point, prior to ARIN coming into existence, it was managed by the National Science Foundation, the NSF. Prior to NSF, allocations for the entire network were managed by the Network Information Center at SRI, SRI-NIC. It was originally a strictly noncommercial, research and educational network which grew out of the older ARPA net, a network funded by the defense department's Advanced Research Projects Agency, DARPA. This is the origin of the use of "arpa" top level domain in the reverse DNS zones of "in-addr.arpa" and "ip6.arpa" that are still in use today. At that time, large blocks of addresses sized by "Class" were handed out directly to organizations and institutions. Loosely, a Class A network was what we now know as a /8 with its 16,777,216 addresses each. A Class B network was the equivalent of the modern /16 with 65,536 addresses each. Finally, a Class C address was the equivalent of a /24 with only 256 addresses. Later, a block sometimes referred to as a Class D was added that later became the multicast block. Some large educational institutions and international companies received entire Class A networks. But there were only 128 of these possible with some of them being unusable such as 0, 10, and 127. Smaller institutions could get Class B assignments and a few had to settle for one or more Class C blocks. There was initially no subnetting, splitting large networks into smaller ones, or supernetting, combining smaller blocks into larger networks, because the routing protocols didn't permit it. It was recognized that, in the majority of the cases, a Class C would be too small and a Class B too large, so the subnetting and supernetting were introduced along with updated routing protocols followed by the Classless Inter-Domain Routing system, which did away with the old Class system entirely. But these huge oversized allocations remained. So the argument goes, "why can't we recover some of this space along with more modern allocations which are no longer routed or in use on the Internet and reallocate to others who need it?" Answer is, "We can. It just doesn't buy us much and aggravates other problems."

First problem with the legacy blocks is that there really isn't as much "slack space" of unroutable addresses in the legacy blocks as some people might hope. One estimate at ARIN was there might be a totally equivalent of 7 more /8s scattered between the blocks. But that's only if you count blocks of space which are unroutable. Some blocks are well known to be allocated and in use but not advertised on the Internet for one reason or another. Reuse of those blocks is simply not possible due to the conflicts they would create across NAT devices with the owners. And even those 7 blocks, assuming they could all be reused, still does not buy us a lot of time.

Another problem with the legacy blocks that are routed is that organizations may have had largely dispersed allocations internally. It's really not practical to go back to organizations and ask them to rejustify their original allocations and to identify slack space in their allocations they could return to begin with. Attempting to break these blocks up to recover that space would be chaotic at best and aggravate other problems such as routing tables at the same time.

As ARIN, RIPE, and APNIC (the 3 original RIRs) were formed along with IANA for furthering commercial development of the Internet, they formalized the process where IANA would hand out blocks on a /8 boundary to the RIRs for further subdivision and allocations to their clients. The reason this boundary was chosen was for purposes of managing the reverse DNS. IANA would manage the in-addr.arpa domain under which the reverse DNS operates and each RIR would be responsible for the [n].in-addr.arpa subdomain for the block, n, which they exclusively controlled. Unfortunately the pre-RIR blocks, the legacy address blocks, are scattered between RIRs complicating management and updates. Breaking down these things further only aggravates this. This is a reason why the RIRs have referred to the legacy address space as "swamp space" due to the management swamp it represents to them. Breaking up any of the /8s (the old Class As) in this way further aggravates this problem by turning a cleanly allocated legacy /8 into potentially being split between RIRs and adding more to the swamp space.

For those three reasons, the RIRs have taken the attitude that the free blocks in legacy space will be the resource of last resort when all else fails and that recovery of allocated legacy space, outside of voluntary return or abuse, is impractical.

Furthering the problems with recovery and reuse are the routing tables themselves. Each time a larger block is broken into smaller blocks at any level above that of the ISP, it adds additional routes to the already overburdened routers. The IPv4 address space is so disorganized and fragmented that the core routers currently have to deal with over 1/3 of a million routes. Both processing power and memory limits are being hammered necessitating ISP upgrades in the core routers. This also severely limits their ability to implement routing best practices such as router policy validation and egress packet filtering which are important protections against route hijacking and spoofing attacks. By making the routing table problem worse, we degrade our ability to fight these two security threats.

However, all of those things considered, the bottom line is still that recovery and reuse is a stopgap measure at best and simply cannot keep up with the current explosive growth of the Internet. The recovered and returned space will not keep up. Recently almost an entire /8 was returned to IANA but that will only delay the inevitable by a mere month or so. Estimates and projections of mobile device usage alone exceed the entire address space of IPv4, allocated, allocatable, private, and unallocated combined. The number of addresses in the 32 bit IPv4 address space from one end to another is only 4,294,967,296. That seems like a mighty big number if you don't stop to think about it but we can simply not support the growth of the Internet as it currently stands in IPv4 without creating and aggravating serious security and operational problems.