Used but Unallocated: Potentially Awkward /8 Assignments
by Leo Vegoda, ICANN

IPv4 has proven to be exceedingly popular, so it should be no surprise that the time is rapidly approaching when the last /8 block will be allocated and the Internet Assigned Numbers Authority's (IANA's) free pool of address space will be empty. At the time of writing, Geoff Huston of the Asia Pacific Network Information Centre (APNIC) is projecting [1] the IANA free pool will run out in mid-2010. Unfortunately, it is possible that some of these remaining /8s may cause problems for enterprise and Internet Service Provider (ISP) network operators when they are put back into use. These blocks are not the /8s that have been returned to IANA by the original registrants; they are previously unassigned address blocks.

Concerns

There are many concerns about the IANA free pool depletion, but one of them seems particularly straightforward to identify and fix. Many organizations have chosen to use unregistered IPv4 addresses in their internal networks and, in some cases, network equipment or software providers have chosen to use unregistered IPv4 addresses in their products or services. In many cases the choice to use these addresses was made because the network operators did not want the administrative burden of requesting a registered block of addresses from a Regional Internet Registry (RIR) [2, 11]. In other cases they may not have realized that RFC 1918 [3] set aside three blocks of address space for private networks, so they just picked what they believed to be an unused block, or their needs exceeded the RFC 1918 set-aside blocks. Other organizations used the default address range suggested by their equipment vendor, or supplied in example documentation, when configuring Network Address Translation (NAT) devices. Regardless of the reason, these uses of unregistered addresses will conflict with routed addresses when the /8s in question are eventually assigned to ISPs or enterprise users.

A few examples of /8s where problems are likely to occur follow:

1.0.0.0/8	Widely used as private address space in large organizations whose needs exceed those provided for by RFC 1918 [4]
5.0.0.0/8	Used by one of numerous zero-configuration Internet applications (including the Hamachi VPN service [5, 6])
42.0.0.0/8	Default range used in the NAT configuration of at least one Internet appliance (the HP Procurve 700wl [7])

Organizations using these address ranges in products or services may experience problems when more specific Internet routes attract traffic that was meant for internal hosts, or alternatively find themselves unable to reach the legitimate users of those addresses because those addresses are being used internally. The users of unregistered networks may also find problems with reverse Domain Name System (DNS) resolution, depending on how their DNS servers are configured. These problems are likely to result in additional calls to helpdesks and security desks at both enterprises and ISPs, with unexpected behavior for end users that might be hard to diagnose. Users of unregistered address space may also experience problems with unexpected traffic being received at their site if they leak internal routes to the public Internet. Many ISPs have already had experience with this type of routing inconsistency as recent /8 allocations reach routing tables and bogon filters are updated.

Alternatives

There are several alternatives to using unregistered IPv4 address space:

• Use RFC 1918 IPv4 address space (no need to obtain this space from an RIR)
• Use IPv4 address space registered with an RIR
• Use IPv6 address space registered with an RIR
• Use IPv6 Unique Local Address [8] space (no need to obtain this space from an RIR)

Obviously, all of these efforts will involve renumbering networks, a sometimes painful and time-consuming process. Those using un-registered unique IPv4 address space should look at renumbering their networks or services before the previously unallocated /8s are allocated to avoid address clashes and routing difficulties.

Additionally, vendors and documentation writers can clean up their configurations to ensure they use RFC 1918 addresses, or make it clear to their users that they must use registered addresses to avoid routing conflicts.

All RIRs provide free telephone helpdesks that can advise you on obtaining unique IPv4 or IPv6 address space. But if you want to continue using unregistered space and can transition to IPv6, the prefix selection mechanism described in RFC 4193 makes the probability of a clash a mere 1 in 550 billion. Ultimately, transitioning to IPv6 is most likely the best solution, and this approach offers an opportunity for those having to renumber parts of their network to avoid a subsequent renumbering later into IPv6.

About IANA and ICANN

IANA allocates address space to RIRs according to the global IPv4 [9] and IPv6 [10] policies. Enterprise and ISP networks need to obtain IP addresses from their upstream provider or from the appropriate RIR.

The Internet Corporation for Assigned Names and Numbers (ICANN) is an internationally organized, nonprofit corporation that has responsibility for Internet Protocol (IP) address space allocation, protocol identifier assignment, generic (gTLD) and country code (ccTLD) Top-Level Domain name system management, and root server system management functions. These services were originally performed under U.S. government contract by IANA and other entities. ICANN now performs the IANA function.