The Internet has boomed in the intervening years and exceeded all our expectations. It now has a fundamental place in the economies of nations around the globe. The boom has gone so far that on February 3rd I allocated the last five blocks of IPv4 addresses from IANA’s central pool to the Regional Internet Registries (RIRs). The RIRs will allocate those IPv4 addresses to the networks in their regions in the coming months and maybe years.

The Internet uses IP addresses for its infrastructure, for the content we access and for the connections of ordinary Internet users. Recent studies indicate that approximately 2 billion people around the world have access to the Internet. And many of those 2 billion people may use 2 or more devices (computers, mobile phones, cable modems) that require an Internet address to deliver the service they want. The few billion addresses in IPv4 are barely enough for the services offered to 2 billion people much less for a world with a population of almost 7 billion.

There will be a period of transition and it will take time for the primary IPv4 infrastructure of the Internet to be replaced by IPv6 infrastructure. That transition will happen though because using the Internet has become an economic driver in all parts of the world.

I want to repeat the call I made in 1995 today because unique addresses are still good. And I urge everyone who anticipates building new Internet services, equipment and connections to provide support for globally unique IPv6 addresses. Having the wealth of unique addresses that IPv6 offers removes constraints that were placed upon innovation by the restricted availability of essential Internet addresses. IPv6 will enable the Internet’s future growth and there will be new opportunities for those already using the Internet as well as for those who will soon begin using it.

The peaks in IPv6 access, which is shown in red on the graph, closely correlate with ICANN meetings. IPv6 connectivity is provided as standard at ICANN meetings and lots of meeting attendees have been using it without knowing while using the free WiFi.

So, as the graph shows, we have had peaks in IPv6 access alongside the October 2009 ICANN meeting in Seoul, the March 2010 ICANN meeting in Nairobi and June’s ICANN meeting in Brussels. There was also a peak in January 2010, which we believe is associated with the IANA Business Continuity Exercise that took place on the 19^th of January, thus users were preferring the IPv6 transport while IPv4 provision was in flux.

What is perhaps more heartening than the peaks associated with the ICANN meetings, is that the troughs in April and May 2010 are far less shallow than those seen in December 2009 and February 2010. There is growth in IPv6 traffic! While at the start of the process we had to use a magnifying lens to see the changes, they are definitely becoming more obvious.

ICANN will continue to assess the adoption of IPv6 worldwide and make reports at regular intervals. ICANN also encourages all organizations to make sure they are – or will be – implementing IPv6 on their networks.

Nonetheless, there are a lot of addresses and lots of new things to learn if you are only familiar with an IPv4 environment. But as we implement IPv6 across our networks we will see IPv6 addresses popping up in mail headers, system logs, traceroutes and all sorts of other places where IPv4 used to be used exclusively. Knowing quickly whether an address is part of your own network or someone else’s; whether an address is intended for private use or Internet use; and knowing whether an address is used by a transition mechanism or a native connection will help save lots of time.

Last year, ICANN staff worked with the staff at APNIC and the RIPE NCC to produce a single sheet that identified the key address groups, explained what they were and gave IPv4 examples of IPv4 equivalents where they existed. This year we have updated the sheet and you can grab a copy of the updated reference from here.

This reference will be useful for anyone working on an abuse desk, in a Network Operations Centre or a corporate IT department. Even if you don’t plan to roll out IPv6 on your own network in the next few months, you are likely to see it appearing on other networks. Using our cheat sheet can help bring you up to speed quickly and identify where to look for an address faster than by just consulting the on-line registries.

We want this reference guide to be as useful and current as possible, so as things change in the future we will produce further updates for you to use.

This month’s episode discusses ICANN’s Registrar Accreditation Agreement. If you’re not familiar with it, perhaps you should be — more than 900 ICANN registrars have signed it, making it one of ICANN’s most foundational documents. Though it has seldom been revised in ICANN’s history, currently, a Working Group contemplates amending it.

Advocates for changing it include individual domain name holders, seeking a “Registrant Rights” charter; and numerous law enforcement agencies have focused on the RAA in hopes of gaining an edge in their fight against cybercrime. To learn more, listen to (or read) Senior Policy Counselor Margie Milam’s briefing in our latest episode of the podcast, entitled simply, “RAA.”

Could RAA amendments unveil cybercriminals? Or might they harm privacy?

If you missed last month’s episode, it’s also well worth your time. Leo Vegoda, Manager of Number Resources, delivered an outstanding orientation on almost every issue related to the fast-approaching shortage of Internet addresses. Whether or not you feel geeky enough to understand IPv4, IPv6, and the differences between them, Leo will help you understand all the ramifications of a worldwide Internet address shortage, what’s being done about it, and how the problem will affect you. If you’ve ever wondered at all about IPv6, check out Episode 5, “What Does IPv6 Mean?”

If you feel you learn better (or faster) by reading rather than listening, I’m pleased to announce that as of this month, every ICANN Start episode now has its transcript sitting right next to it. We’re continuing our effort to make the podcast a useful starting point when you want to understand an ICANN issue that is new to you. The ICANN community has responded, with the number of downloads during the podcast’s second month soaring north of 1,000. Thank you for your support!

What else would you like to hear a basic orientation about? Send an email to start@icann.org, where we’re watching for your input.

The networks using these officially unallocated addresses are intended to be private, not visible to the global Internet. Nonetheless, their use can be detected when the private parts of networks connect to their public Internet facing connections, such as the connections to their service providers. The addresses leak in e-mail message headers, DNS queries and other random traffic. In some cases, this unofficial use can cause operational problems.

IANA staff has tried to research which /8s are being used in this way. In 2008 we sponsored research by Duane Wessels into which /8s see the most use. He reported on his research at OARC’s DNS Ops meeting and I wrote about it on this blog. Based on this work, we think the /8s with the most unofficial use are:

1, 2, 5, 14, 23, 39, 42, 100, 101, 107, 175 and 176

Duane Wessels’ research was part of a number of presentations that were part of an awareness campaign we worked on. This included talks at network operator groups and articles in industry journals and in some cases discussions with the users of the unallocated space where we could identify them. While we have discussed the issue with some of these network operators, we haven’t been able to speak directly to everyone making unofficial use of this address space because they tend to do so in private networks.

We know that newly allocated IPv4 /8s can be difficult for assigned users to use at first because old filters which block unallocated addresses are slow to be updated with new allocation information. There might be some extra operational difficulties with these particular /8s if unofficial users of the addresses try to communicate with the newly assigned official users of the same addresses.

The longer-term solution to this problem is for network operators to switch to IPv6 and to stop using the unallocated blocks entirely.

Over the next two years we will continue to allocate from these /8s when making allocations to the RIRs. The RIRs use about one /8 per month and so over the next couple of years we know that all of these /8s will be allocated.

One of the more interesting insights involved looking at network diversity. We want top-level domains to keep functioning no matter what is happening — any conceivable disaster shouldn’t knock a top-level domain off-line. One thing we ask is that top-level domains’ name servers be hosted in at least two distinct networks, so it is guarded against a failure (be it a technical failure, or some other business failure event).

Here is a map of all the country-code top-level domains, and one possibly measure of diversity — the number of “autonomous systems” their name servers are hosted in. Countries marked red are reliant on a single network, and if that network failed it could be disastrous for its users without alternatives. Those orange through green have increasing amounts of diversity in the networks that host their name servers:

If we take a minimum of two networks as our baseline requirement, we can look at how TLDs have met this criteria over a period of time — say the last five years:

The blue line shows IPv4 connectivity and it is pretty good, and rather consistent. But if we judge IPv6 connectivity against the same diversity requirement, shown as the green line, not even 50% of ccTLDs have this level of diversity. If we look at TLDs with any IPv6 it is a little better, but there is still about a third of all ccTLDs with no IPv6 connectivity at all!

The good news is the IPv6 trend lines are heading in the right direction, with the growth of IPv6 deployment even accelerating a little recently. Lets hope this continues so that these critical resources are stable not just for existing Internet users, but for future Internet users as well.

L.root-servers.net, operated by ICANN, became the seventh of the root servers to have it’s IPv6 address records (AAAA) added into the DNS root-zone. The addition of IPv6 service is part of ICANN’s ongoing commitment to act as a leader in enabling IPv6 services throughout the DNS.

The new IPv6 address is 2001:500:3::42

To access this service DNS operators should update their hints files. In fact checking that you have the latest hints file on a regular basis is always good operational practice.

The latest hints files are available at the following URLs:

ftp://rs.internic.net/domain/named.root
ftp://ftp.internic.net/domain/named.root

The root servers currently answering on IPv6 are:

A.ROOT-SERVERS.NET 2001:503:ba3e::2:30
F.ROOT-SERVERS.NET 2001:500:2f::f
H.ROOT-SERVERS.NET 2001:500:1::803f:235
J.ROOT-SERVERS.NET 2001:503:c27::2:30
K.ROOT-SERVERS.NET 2001:7fd::1
L.ROOT-SERVERS.NET 2001:500:3::42
M.ROOT-SERVERS.NET 2001:dc3::35

Unfortunately, even when production quality IPv6 transport and network infrastructure are available it is not always possible to deploy a completely IPv6 accessible network. One problem is the difficulties domain name registrants have when they ask their domain name registrar to include their IPv6 glue in the DNS. Not many domain name registrars support glue registration for IPv6 addresses. This limits their ability to provide an IPv6 DNS service.

The problem was discussed during Registries and Registrars’ IPv6 workshop on the last day of the ICANN meeting in Paris. Raúl Echeberría explained the problems that LACNIC has experienced in registering the glue they need for ns.lacnic.net.

Mohsen Souissi of AFNIC then explained that IPv6 support in domain name registries is no longer the hard work it once was. Most of the tools that are needed already support IPv6 very well and have done so for some time. He was followed by Jean-Claude Michot of BookMyName who explained that introducing support for IPv6 glue was not a complicated process and was done very quickly.

It is possible for a registrar to provide support for IPv6 glue registration without running IPv6 on their network at all and deploying an IPv6 network is now far less painful than it once was. Michele Neylon from Blacknight described a generally positive experience.

We hope that more domain registrars will start offering IPv6 glue registration, which will make it easier for domain name registrants to go ahead and deploy their own IPv6 networks.