Skip to main content

Recovering IPv4 Address Space

More IPv4 /8s returned to an “IANA – Reserved” status in 2007 then ever before.

With help from the Regional Internet Registries, three /8s were returned in 2007 and last month we recovered one more. We now have 43 unallocated /8s. Here’s a table showing the details of the returned blocks.

/8 Year Help from
46 – BBN 2007 BBN and ARIN
49 – US DoD 2007 ARIN
50 – US DoD 2007 ARIN
14 – Public Data Net 2008 Network Operators

Despite this windfall we are unlikely to see any more whole /8s returned to the IANA free pool. Our investigations indicate that the other legacy “Class A” assignments are all at least partially used. Recovering the space in those blocks would require large companies to engage in expensive renumbering exercises.

But more importantly, it would not buy us very much time. We allocated more than one /8 per month in 2007, so to gain even one year would require a huge amount of renumbering by the users of more than a dozen legacy assignments.

Geoff Huston’s mathematical projection suggests the IANA free pool will be empty before the second half of 2011 and the RIRs’ pools will run out barely a year later. Of course, whatever mathematical models he uses, he cannot account for the very human possibility of a run on the bank.

Address recovery cannot extend the life of the IANA free pool by more than a few months.

It is possible that unused portions of the legacy “Class A” and “Class B” will be returned to the RIRs free pools. Alternatively, it is possible people with partially used legacy assignments will wait for a variant on the policy proposals in the RIPE and APNIC communities to emerge and then engage in remunerated renumbering and address transfer programs.

Whatever actually happens in the next few years, we can be sure that anyone needing large amounts of address space for a rapidly growing network will have to deploy IPv6. IPv6 deployment in the Internet’s core infrastructure is continuing and network operators at ISPs and enterprises need to plan for a world where their users will need to communicate with systems on both IPv4 and IPv6.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."