Home / Blogs

Current ICANN Policy Precludes the ITU Becoming an IP Address Registry

Lost in all the discussion around the recent ITU meeting (TIES account required of course) is any discussion of the current policy regarding the formation of new RIRs.

You may recall that one of the reports that the ITU commissioned on this subject suggests that it would be possible, even desirable for the ITU to be allocated a /12 of IPv6 from the IANA to be further allocated to Country Internet Registries.

Here is why that idea can’t possibly happen:

1) The region of coverage should meet the scale to be defined by ICANN, given the need to avoid global address fragmentation

The proposed RIR must operate internationally in a large geographical region of approximately continental size.

Each region should be served by a single RIR, established under one management and in one location. The establishment of multiple RIRs in one region is likely to lead to:

• fragmentation of address space allocated to the region;
• difficulty for co-ordination and co-operation between the RIRs;
• confusion for the community within the region.

This document, which was accepted in 2001 by the ICANN Board of Directors as “a statement of essential requirements for the recognition of new Regional Internet Registries (RIRs), in supplementation to section 9 of the ASO-Memorandum of Understanding, and acknowledged it as a framework for consideration of applications for recognition of new RIRs.” sets out a number of principles that clearly delineate how to start a new RIR. The fact that the ITU commissioned report doesn’t even meet the first principle seems to indicate that the “researchers” didn’t do their “research”.

There are other “Principles” enshrined in this policy as well, which could arguably exclude the ITU from taking on this role:

2) The new RIR must demonstrate that it has the broad support of the LIRs (ISP community) in the proposed region

3) Bottom-up self-governance structure for setting local policies

4) Neutrality and impartiality in relation to all interested parties, and particularly the LIRs

5) Technical expertise

6) Adherence to global policies regarding address space conservation, aggregation and registration

One doesn’t need to argue them at all however, as the first principle clearly excludes the duplication of the RIR functions according to Dr. Ramadass plan. Obviously, if the ITU were to set up a global registry, it would violate the “approximately continental size” requirement, and if there were a global “RIR” run by the ITU it would run afoul of the requirement that “Each region should be served by a single RIR, established under one management and in one location.”

So it’s a non-starter, its quite clear, it just can’t happen according to the current policy. However, since one of the the outcomes of the ITU meeting held on March 15th and 16th is two email “correspondence groups”, one to study outreach and capacity building about IPv6, and the second to study the concerns that developing nations have about IPv6 distribution and how the existing RIR system can address them, it seems we are still going to be discussing this issue going forward.

In the East African country where I live, I have been asked to sit on a 4 person ad hoc committee to further discuss what the “national position” should be on this topic. In my opinion the “national position” should be “let’s just get on with IPv6 deployment and quit worrying about who does the allocating, as that is not going to change!”

By McTim, Internet policy and governance consultant

Filed Under


The fact that it can't happen does not mean it won't Phillip Hallam-Baker  –  Jul 19, 2010 1:22 AM

There is no way that ICANN will permit the ITU to establish a registry, but there is absolutely nothing to stop the ITU from going ahead of its own accord.

IPv6 address space is not scarce. There is no particular reason that there should be a single administrative center - provided that they do not overlap.

The same sort of thing has already happened in the MAC address space. When the storage companies asked for a chunk of MAC address space, IEEE told them to get lost. So the storage people went ahead and declared a chunk of space to be ‘theirs’ and issued enough company prefixes to make it a fait accompli. And now there is a hole in EUI48 space for the storage manufacturers.

The real question would be whether backbone providers were prepared to route it. And that in turn is really a function of how badly the powers that want to challenge ICANN want that to happen and whether anyone is willing to go to the mat to defend ICANN’s turf for them.

Apart from ICANN and the RIRs, maintaining the ICANN monopoly on allocation is not in anyone’s interest. The US has identified a national interest in preventing the ITU gaining control, but what is proposed here does not amount to that. On the contrary, it makes it highly unlikely ITU ever gains more than a share of control.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign


Sponsored byVerisign

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API