Wampum

A friend of MB's, now a 2L at Bolt, sent me a copy of a work in progress. It is a framework unstated paper, that is, a trademark policy and practice paper uninformed by other policy considerations. Because of the policy development work I'm doing, in part so that municipal TLD proposals don't get blocked ab initio by trademark, and other interests, some of which may have no interest at all, under any policy framework, intellectual property, competition, self-interest, in any TLD proposals, municipal or otherwise, ever being added by ICANN to the IANA root, I wrote the sketch of an IANA function framed paper considering only the address consumption resulting from domain name speculation. This appears below.

The Internet Assigned Numbers Authority (IANA) is responsible for the global coordination of the DNS Root, IP addressing, and other Internet protocol resources. These responsibilities, and the IANA contract, are unchanged by the change from the ICANN MoU regime to the AoC regime, which took place on Sept. 30th, 2009.

The IANA function consists of three sub-functions:

1. it manages the DNS Root Zone (assignments of ccTLDs and gTLDs), as well as the .int registry, and the .arpa zone,
2. coordinates the global IP and AS number space, and allocates these to Regional Internet Registries, and
3. is the central repository for protocol name and number registries, used in many Internet protocols.

Is domain name speculation observable from the point of view of the IANA function?

This activity has generated on the order of 35 million name to address mappings, consuming between 1 and 35 million IPv4 addresses. Name based virtual hosting has replaced address based virtual hosting, however, assuming only that aggregated load limits the number of marginally profitable names assigned to a host, whether only one, or more than one IP addresses are bound to a single network interface, or the host has multiple network interfaces, and that 1 thousand names is the optimal density for commodity hosts and commodity hosting contracts, 35 million names requires no fewer than 35,000 unique addresses. The largest observed concentration known to the author is an order of magnitude smaller, so the actual use may be on the order a third of a million unique IPv4 addresses.

It is therefore not possible to avoid the conclusion that name space speculation consumes the address resource equivalent of a medium to large access network. In classful terms, the resource consumption is bounded below by half a Class B allocation (65,534), and bounded above by two Class A allocations (16,777,214). In CIDR terms, by a /17 (32,766) and a /7 (33,554,430) allocations. It is therefore "observable" from the point of view of the IANA's number space allocation function. We're down to our last 5 /8 blocks globally, a /7 is two of them.

The qustion asked, "Is domain name speculation observable from the point of view of the IANA function?" must be answered in the affirmative.

The data available suggests a best fit predictive model where the first RIR will exhaust its available pool of addresses and no further numbers are available in the IANA unallocated pool to replenish the RIR's pool will occur on 17-Oct-2012. [1]

Therefore, assuming that exhaustion of the unallocated pool of IPv4 address for any regional Internet Registry (RIR), and a cessation of address allocation results, or a recovery regime which entails efficient breech [2] is instituted, is a non-desirable policy outcome, domain name speculation, as practiced, constrained only by commodity hardware load and commodity hosting provisioning capabilities, is contrary to the basic policy implemented by the IANA's address space management function.

This harm may be reduced by reducing the address resources domain name speculators consume. This could be accomplished through a technical density requirement that domain speculators use specific /22 allocations, or through other policy means, including those which tend to reduce the return on investment to domain name speculators, and result in substantive IPv4 address recovery.

[1] http://www.potaroo.net/tools/ipv4/index.html

[2] http://en.wikipedia.org/wiki/Efficient_breach