Guided by Richard Clayton, NPL has established a collaborative study team of domain specialists from three universities. Together, this team will examine the extent to which gTLD domain names involved in illegal or harmful Internet activities are registered via Privacy or Proxy services to obscure the perpetrator’s identity. Study results are expected in early 2013.

This study is being launched to help the Generic Names Supporting Organization (GNSO) and ICANN community better understand how often alleged bad actors obscure their identities using several common methods, including (but not limited to) Privacy/Proxy registration. By examining a variety of illegal or harmful Internet activities, including phishing, malware distribution, money laundering, unlicensed pharmacies, typosquatting, child sexual abuse images, spam, and cybersquatting, NPL will measure the percentage of associated gTLD domain names registered via Privacy or Proxy services, as well as the proportion of those registered with inaccurate or incomplete WHOIS details or stolen identities.

To determine whether Privacy/Proxy use is significantly greater among domains involved in illegal or harmful activities, NPL will compare alleged bad actor percentages to the 16-20% overall percentage found by ICANN’s 2010 Study on the Prevalence of Domain Names Registered Using Privacy or Proxy Services among the top 5 gTLDs. Beyond placing bad actor percentages into context, this study will not attempt to analyze broader use of Privacy/Proxy services by domains registered for entirely lawful purposes.

NPL is one of Europe’s leading National Measurement Institutes (NMI). Along with other NMI’s including the U.S. National Institute of Standards and Technology (NIST), NPL works with industry and government to develop the latest state-of-the-art measurement techniques for all areas of science and technology.

To learn more about the Whois Privacy and Proxy Abuse Study, visit: http://gnso.icann.org/issues/whois/index.html

These regional events are a chance for ICANN staff and representatives from gTLD registries and ICANN-accredited registrars to meet informally to discuss topics important to our industry and business relationships. These events happen regularly and in different locations around the world. Previous events, for example, took place in Tokyo, Munich, Toronto, and Rome.

Although the event is tailored to regional ICANN-accredited registrars and gTLD registries, others located around the globe that may have a regional or business interest also attend.

The agenda is not final yet, however some of the anticipated agenda items are:

• New gTLDs update, ICANN Registry and Registrar departments operational readiness
• Developments in Contractual Compliance
• IDN Developments
• GNSO Policy Development
• Policy updates

The regional event model was introduced in 2006 as an educational opportunity for ICANN and its contracted parties to share information about registry and registrar operations within the domain name industry. The events have largely been focused on the policies and procedures registration service providers are obligated to implement and enforce as a result of either their contract with ICANN or with one another.

These regional events are distinguished from the regular international ICANN meetings in that they are not structured, for example, to influence policy development. If you are interested in the policy development and a broader interaction with ICANN stakeholders, please join the upcoming ICANN Meeting in Prague in June this year.

All presentation materials will be published on the ICANN website after the event.

The space to attend this event is limited and interested registrars and registries are asked to pre-register. Others parties who may be interested in becoming an ICANN-accredited registrar or gTLD registry and wish to attend as observers should contact regionalevents@icann.org for further details.

We look forward to seeing you in Los Angeles!

Internet networks learn how to reach destinations (IP addresses) using an IETF protocol called the Boarder Gateway Protocol (BGP). BGP uses unique Autonomous System (AS) numbers to identify individual networks (routing domains) in order to announce the reachability of destinations (IP addresses). Originally, BGP used 16-bit numbers, allowing slightly more than 65,000 ASs

Internet growth in the 1990s made it clear that a 16-bit number space is insufficient and the first proposals for a 32-bit number space, allowing about 4.3 billion AS numbers, were published in 2001. In parallel with this work, the addressing community began developing a transition policy in the RIRs’ open policy forums and socialising it with network operators, the consumers of AS numbers.

The IETF work was published as a standards track RFC in 2007. And while IPv4 and IPv6 networks do not interoperate, networks that don’t know about 32-bit AS numbers can still communicate with networks using 32-bit AS number using a transition mechanism described in the RFC. The RIR community work was ratified as a Global Policy in 2008 and included a timetable for the transition. This echoed the timetables the addressing communities had agreed to in the policies governing AS number assignments in each of their regions.

These regional policies have promoted 32-bit AS number assignments and now require the RIRs to treat all AS numbers as part of the same 32-bit pool. Unfortunately, lots of networks reported problems making use of 32-bit ASNs. In the region served by the RIPE NCC, which has had the most success at assigning 32-bit ASNs [PDF, 2.66 MB] (PDF slides 8 & 9), they still comprise just a third of the total ASN assignments. The reason for the huge disparity in acceptance between the five regions is not clear. Earlier this month, John Curran, ARIN’s CEO & President, asked the ARIN community for an easy, straightforward answer to this question.

One of the reasons networks have problems deploying 32-bit AS numbers is that network providers who have not upgraded their equipment will see the same transition AS number being used by different network providers. This duplication of AS numbers causes problems for monitoring tools and even path selection mechanisms. But there are just three blocks of 16-bit ASNs left, so the time is rapidly approaching when networks won’t be able to swap out a 32-bit AS number for a 16-bit replacement AS number. There won’t be any new 16-bit AS numbers left.

Much has been written about the lack of IPv4 addresses and its impact on the potential economic growth of countries and industries.  The need to transition to IPv6 has triggered coordinated action plans from major network, content and access providers to support both IPv4 and IPv6.  However, little attention has been paid to the diminishing pool of 16-bit ASN numbers, which are another enabler of Internet growth.  The technical community has defined a 32-bit ASN specification; the addressing communities have implemented suitable assignment policies; what is now needed is widespread acceptance of 32-bit AS numbers by network providers.

Last week at my first ICANN meeting as regional Vice President for Latin America and the Caribbean, I was proud that all my ICANN colleagues converged on Costa Rica and were able to see for themselves why I love the Latin American and Caribbean region. Besides the friendly people, great food, wonderful climate and natural beauty, there is also a thriving, dedicated Internet community.

One such organization deserves special recognition: LACTLD, the Latin American and Caribbean Top-Level Domain Organization. From 8 to 10 March, just overlapping the ICANN 43 meeting in Costa Rica, LACTLD held its Economic Affairs Workshop. More than 15 ccTLD managers from the region attended the workshop and were able to join the ccNSO activities.

LACTLD was born in pre-ICANN times when communication among ccTLDs was not formalized, but was already necessary. LACTLD has two types of members:

• Associate members, which include any Latin American and Caribbean ccTLD; and
• Affiliate members, which are any ccTLD outside the Latin American and Caribbean region, as well as any gTLD with particular ties with the region.

LACTLD is one of the first regional organizations to be represented in ICANN. Its objective is to represent the region´s TLD interest in global policy-making fora.  Since its creation, it has organized dozens of workshops all over the region with primary focus on DNS operations.  In the next two months, LACTLD has workshops and conferences coming up in Bogota and Cartagena, Colombia; Ecuador; and Argentina, with more coming later this year in El Salvador, Uruguay, and elsewhere. LACTLD is also joining in next week at the first Brazilian forum on computer emergency response for organizations during disasters and accidents.

ICANN acknowledges the importance of the ccTLDs in the ICANN community. They are cornerstones in our multi-stakeholder model. Their voluntary cooperation and coordination with one another make significant contributions to the vision of “one world, one Internet.”

ICANN recognizes the vital job that LACTLD and its membership do in the region. I hope you’ll join me in applauding their contribution toward maintaining a secure, stable, globally interoperable Internet.

So, all in all, how many resolvers are there? Given that anybody can run one, it seems like a difficult thing to measure. It turns out, however, that all resolvers that talk directly to authoritative servers on the Internet leave a trail, and with a little data crunching we can come up with a number.

Back in 2010, ICANN, VeriSign and NTIA concluded a successful collaboration to deploy DNSSEC [TXT, 52 KB] in the root zone of the DNS. As part of that project, Root Server Operators collected DNS requests that were delivered to their individual Root Server infrastructure, and deposited the resulting data with DNS-OARC for analysis.

The goal of this data collection exercise was to try and identify any potential problems for DNS clients due to DNSSEC deployment. The by-product of this exercise, however, is a data set which provides insight into DNS traffic between a highly-representative set of DNS resolvers and DNS authority servers (almost all resolvers talk to a root server every once in a while).

One of the data collection exercises carried out had a particularly long time-base. The collection is referred to as "LTQC" (Long-Term Query Collection) and it concerned itself just with priming queries, that is, the initial query that every resolver sends to a root server when it starts up in order to obtain an up-to-date set of DNS root server names.11 of the 13 root servers contributed data to this collection, including L-Root, the root server operated by ICANN. Data was collected between November 2009 and July 2010.

So, here’s our methodology: we look at every request contained in the LTQC packet-capture, and count the number of unique IPv4 and IPv6 source addresses.

During the collection period, we saw 9,945,017 unique source addresses, of which 59,489 (0.60%) were IPv6 and  and 9,885,528 (99.40%) were IPv4.

So which resolvers won’t we see?

We won’t see internal resolvers that don’t send queries to authoritative servers on the Internet directly, but instead send them via other intermediate resolvers. Included in this class of resolver are any that are hidden behind middleboxes that redirect DNS queries to a central cache, or otherwise change normal priming behaviour.

We won’t necessarily see internal resolvers that are deployed behind a Network Address Translator (NAT) — at least, in such a situation we might see only some of them.

We won’t see resolvers that started (and primed) before the data collection period started, and then never primed again before the end of that period.

We obviously won’t see any resolvers that were brought live after the collection period ended, and we assume that the number of resolvers is probably increasing due to the general growth of the Internet.

Any resolver that was renumbered during the collection period (and primed before and after the renumbering event) would be counted twice. Intuitively, this seems like a minor effect; we think most resolvers are renumbered fairly infrequently, since they are generally referred to by address rather than name.

Given the expected errors in the number we measured due to the effects described above, it seems appropriate to round the answer to a single significant figure; this at least gives us an order of magnitude for a lower bound.

What we are left with? That there are at least 10 million DNS resolvers on the Internet today.

As Latin American Internet users look on, Raul Echeberria (left), Executive Director of LACNIC, and Rod Beckstrom, President and CEO of ICANN, sign mutual agreements at ICANN 43 in Costa Rica.

San Jose, Costa Rica – At the ICANN 43 meeting ongoing this week, the Latin American and Caribbean Internet Addresses Registry (LACNIC) and the Internet Corporation for Assigned Names and Numbers (ICANN) signed an agreement pledging to work together to increase the number of L-Root locations in Latin America and the Caribbean.  

“L-Root” refers to one of thirteen computers that anchor the globe’s Domain Name Service (DNS). Where computers locate one another on a network by numeric address, humans find it easier to use and remember names (for instance, users typically remember “ICANN.org” more easily than its IP address, 2620:0:2d0:200::7.) The Domain Name System matches domain names with their correct numeric addresses on the Internet.

There are 13 “root,” or fully authoritative, DNS servers, identified by alphabetic letters A through M — the “L” root being one. Spreading the root information out geographically by duplicating the root servers leads to a resilient, dispersed system that cannot be taken offline by a problem at any single instance of a given DNS root server.

Under the signed agreement, LACNIC is willing to help ICANN strengthen the resilience of the DNS further by adding additional physical locations that host the L-Root. LACNIC will help identify suitable locations and will also finance the required equipment in each location.

Raul Echeberria, Executive Director of LACNIC, commented, “We are very pleased with this agreement signed with ICANN, which will allow LACNIC to extend the work done since 2004 with the project +RAICES. It is a concrete contribution to improve the stability and the benefits of the Internet in the region of Latin America and the Caribbean.”

Rod Beckstrom, President and CEO of ICANN, said, “We thank LACNIC for giving us this magnificent opportunity to continue to deploy the L-Root in this region and to strengthen our relationship with LACNIC. Having a diversity of locations for name servers strengthens the global Internet.”

14 March — ICANN welcomed members of the Commonwealth Cybercrime Initiative (CCI) Steering Group to Costa Rica as part of its efforts to improve the security, stability and resiliency of the global Domain Name System (DNS).

The meeting offered Steering Group members the opportunity to explain the purpose of the Initiative to the ICANN community.

The proposal for the Initiative was developed through the COMNET Foundation for ICT development, an independent foundation which leads the Commonwealth Internet Governance Forum.

The objectives of this Initiative, as stated on the CCI web page, are “to assist developing Commonwealth countries to build their institutional, human and technical capacities with respect to policy, legislation, regulation, investigation and law enforcement with the aim of, making their jurisdictions more secure by denying safe havens to cyber criminals, and enabling all member countries to become effective partners in the globally coordinated effort to combat Cybercrime.” <http://www.commonwealthigf.org/cybercrime/the-commonwealth-cybercrime-initiative/>

These objectives encompass a wide range of anticrime activities, including preventing abuse of the DNS, and are thus consistent with ICANN’s core values and its obligation to enhance and protect the security and stability of the Internet name system. ICANN participates on the Initiative Steering Group and has expressed its willingness to assist the Initiative in capacity building associated with DNS operations and security. 

ICANN Chief Security Officer, Jeff Moss, said, “Through this cooperative relationship, ICANN will also assist Commonwealth member countries with DNSSEC deployment. An important goal for ICANN and the Initiative is to work to have all member countries sign their Top Level Domain zones.”

The workshop at the ICANN meeting in Costa Rica is part of an effort to “translate the CCI concept into an operational reality in assisting member countries in building coherent and sustainable capacity on the ground to help make the Internet a safer place,” said Joseph Tabone, Chairman of COMNET Foundation for ICT Development. “We thank partners for their continued support and especially thank ICANN for their opportunity to present the Initiative to their community.”

Workshop presentations from Steering Group members and ICANN staff can be viewed at http://costarica43.icann.org/node/29901.

ICANN operates L-Root, one of the 13 Domain Name System root servers which together make up the infrastructure known as the Root Server System. The Root Servers serve the root zone of the DNS, maintained by ICANN staff in the IANA department. The Root Zone provides signposts for familiar Top Level Domains like CA, NZ, UK, NET and ORG, which in turn provide signposts to sub-domains, and hence DNS servers all over the world can find their way to providing their users with answers. If you can’t reach a Root Server, then the rest of the DNS (given time) will become unavailable. It follows that reliable access to a Root Server is pretty important.

At ICANN, we have spent quite a bit of time looking at how we can make Root Server service more reliable for end users in remote and underserved locations. We’ve seen ISPs cut off from all Root Servers due to under-sea cable cuts and satellite transmission failures; we’ve also seen routing errors several networks away cause performance to Root Servers to be sporadic and unreliable. Like every other service on the Internet we also occasionally see big spikes of traffic and that traffic has the potential to make networks between a user and a Root Server congested. No matter how much computing power is installed in regional Root Server clusters, there’s always the chance that a Root Server is difficult to reach from somewhere.

Our conclusion is that a model to make Root Servers, and L-Root especically, more accessible to everybody is to move closer to end users, no matter where the end users happen to be. Fortunately, there’s a good, simple and effective mechanism to make this happen, and it’s called anycast [PDF, 125 KB].

Anycast allows us to install many instances of the L-Root service in underserved areas, so that any particular DNS client that needs to send a request can get an answer locally. If the local instance disappears (perhaps there’s a power cut, or a network problem between you) then your traffic should automatically re-route elsewhere.

How close is the closest L-Root server to you? It’s not that hard to find out. From the Windows command window you can type “tracert L.ROOT-SERVERS.NET”, and from the Macintosh Terminal or a shell on a Unix or Linux computer, “traceroute L.ROOT-SERVERS.NET”. The resulting output will show you the addresses (and, in many cases, DNS names) of the routers between you and L-Root.

For a more geographic perspective, you can take a look at where L-Root is deployed in the world and also where other Root Servers can be found, since we’re certainly not the only Root Server Operator doing this.

ICANN is continuing to identify geographic locations that may be underserved by the Root Server System. Together with network service providers and carriers, we are helping to make the Root Server System more reliable and accessible for users of the Internet, improving the security and stability of the DNS.

This thought paper [PDF, 449 KB] offers guidance for anyone who prepares an order that seeks to seize or take down domain names. Its purpose is to help preparers of legal or regulatory actions understand what information top level domain name (TLD) registration providers such as registries and registrars will need to respond promptly and effectively to a legal or regulatory order or action. The paper explains how information about a domain name is managed and by whom. In particular, it explains that a seizure typically affects three operational elements of the Internet name system ­ domain name registration services, the domain name system (DNS) and WHOIS services ­ and encourages preparers of legal or regulatory actions to consider each when they prepare documentation for a court action.

The thought paper has been prepared by ICANN’s Security team, its authors and contributors are technical and operational staff, not attorneys (although persons with legal expertise were consulted in the preparation of this document). We will have members from the Security team at the upcoming ICANN meeting in Costa Rica and look forward to discussing this with the community.

In early 2011, the RIPE NCC shared some graphs that showed the percentage of IPv6-enabled networks over time. More precisely, it showed the percentage of Autonomous Systems (ASes)¹ that announced one or more IPv6 prefixes in the global routing table. The results for the five Regional Internet Registries (RIRs) were described in the article Networks with IPv6 Over Time on RIPE Labs.

When that article was posted, the percentage of ASes announcing one or more IPv6 prefixes in the five RIR service regions were approximately:

APNIC 10%;

RIPE NCC 8.5%;

LACNIC 8.5%;

AfriNIC 6%; and

ARIN 5%.

The progress has been updated since then, and in the image below you can see the current status in all regions. You can find this interactive graph at http://v6asns.ripe.net and use the tool to plot graphs based on the regions or countries you are interested in.

The percentage of IPv6-enabled networks has increased in all regions. And what is striking is that, although their start and end positions are different, the growth curves for all five regions is remarkably similar. Now, the percentage of ASes announcing one or more IPv6 prefixes in the RIR regions are approximately:

APNIC 17%;

RIPE NCC 15%;

LACNIC 14%

AfriNIC 12%; and

ARIN 10%.

It is interesting to note that all regions showed exponential growth up to mid-2011. This could have multiple causes: ICANN’s IANA Department allocated the last IPv4 address space to the RIRs in February 2011. The World IPv6 Day took place in June 2011, which motivated many organisations to push their IPv6 deployment dates forward. The flattening of the graphs for most regions after that date could also be related to the economic situation in many countries. These possible reasons for the growth similarities all reflect events that impacted globally as opposed to in one RIR region.

We also looked at the countries with the highest IPv6 penetration worldwide and found that many aspects can lead to high IPv6 penetration in a given country. Training is certainly useful, but a strong operational community together with an active government or regulator that encourages IPv6 deployment also seems to have positive effects. In some countries, peer pressure and competition among ISPs also seems to be a factor that helps with IPv6 deployment.

For more information and other graphs, please refer to the background article on RIPE Labs: Networks with IPv6 – One Year Later.

More information about IPv6 can be found on IPv6ActNow.

Guest post by Mirjam Kühne, Labs Community Builder at the RIPE NCC

¹ An autonomous system (AS) refers to either a single network or a group of networks that is controlled by a common network administrator on behalf of a single administrative entity (typically an Internet Service Provider (ISP).