The problem is that the unofficial usage makes it more difficult for ISPs to bring these addresses into use when they are officially allocated and so less desirable. But we have to allocate IPv4 addresses to the RIRs as long as we still have them and they still request them. We just need to implement a mechanism to select which /8 is allocated to which RIR.

The mechanism we have implemented reserves two of the /8s showing the least unofficial use for each of the newest RIRs. AfriNIC and LACNIC have fewest IPv4 /8s and service the regions with the most developing economies. We decided that those RIRs should have four of the easiest to use /8s reserved for them.

The other /8s are split between two pools and when APNIC, ARIN or the RIPE NCC qualify for additional IPv4 address space they will be allocated one /8 from each pool, with the /8 being chosen using a verifiable random selection mechanism. The mechanism is based on the “Publicly Verifiable Nomcom Random Selection” mechanism described in RFC 2777.

The sources of randomness used are the prices of the FTSE 100, Dow Jones Industrial Average and Hang Seng Index from midday at the exchange site the day after the request is received, as published on the Yahoo! Finance web site.

The pool of /8s which have been used to number IP networks in an unofficial and improper way is larger than the other pool. So when the smaller pool runs out, all allocations to APNIC, ARIN and the RIPE NCC will come from the larger pool until it too is empty. Then, if any of the /8s reserved for AfriNIC and LACNIC have not been allocated they will become part of a single pool used for all RIRs.

Of course, when all of this is done, there are still five /8s set aside for the implementation of the Global Policy for the Allocation of the Remaining IPv4 Address Space. Very little use of those /8s was detected in our 2008 research.

As has been discussed a lot lately, the DNS does not have much in the way in inherent security mechanisms. DNSSEC is a newer technology designed to remedy that by adding a layer of cryptographic verification to the DNS. By using DNSSEC, DNS data can be checked and verified to make sure it has not been tampered with in transit over the unprotected Internet.

Key to deploying DNSSEC is deploying it at the root zone level. The root zone is the upper most level in the DNS hierarchy, and is managed under a complex arrangement involving not only ourselves, but also VeriSign and the US Government. Right now, consultations are being made on how best to secure the root zone using DNSSEC, and that discussion is expected to carry on for some time. It is a somewhat political debate, as well as a technical discussion on how to maintain the robustness of a service that is the cornerstone of Internet stability.

The community has recognised that discussion will undoubtedly carry on for some time, but that there is an immediate need to support nascent DNSSEC deployment efforts. To do this a trust anchor repository was proposed, with ICANN requested to operate the service. A trust anchor repository would be a place to hold the security information that would be in the root zone if it were signed. For example, the Swedish country code top-level domain .SE has already implemented DNSSEC, and their trust anchors can be found in the repository. This allows for early adopters who have suitably configured DNSSEC software to obtain that security information independent of the DNS, without waiting for the root zone to have DNSSEC implemented.

Today we have released the first public version of the trust anchor repository after some initial experimentation with some of the core DNSSEC engineering community. We have prepended the word “interim” to its name, just to emphasise that this isn’t permanent, and is only designed to be a stepping stone to the ultimate goal of a DNSSEC-signed root zone.

We do not recommend it for use other than by expert administrators. It is experimental and requires some understanding of DNSSEC to be helpful. We think it will be useful in giving everyone involved better operational experience with DNSSEC, as well as being a helpful nudge on the way toward more universal DNSSEC deployment on the Internet. As a temporary solution, it has its caveats, and we recommend not treating it as an ultimate solution. But with that in mind, we look forward to those who are feeling adventurous to give it a try and provide us with feedback on how we can improve the service.

Last year, we shared some concepts with the community on how we’d like to improve it. First and foremost was making IANA’s purpose clear, and its key information easy to find. Based on the initial feedback, we are almost ready to launch a completely new IANA web site.

We have literally begun from scratch. All web pages have been rewritten, and their place on the website rethought. We are working towards fully standards compliant pages that work in many different browsers. We have also tried to lay a foundation so we can much more easily add new materials and features to the IANA website once it is launched.

So now that we have almost finished the conversion of the site, it is a great opportunity to offer a sneak peek and gather feedback on the almost final product. Our aim is to integrate your feedback, as well as tidy up the remaining rough edges, over the next few weeks. Once we are confident everything is working, we will then replace the existing IANA site.

The new site is at http://beta.iana.org/. Take a look and tell us what you think in the comment area below.