Internet Corporation for Assigned Names and Numbers

On 17-18 May 2012, ICANN and its gTLD registration services providers will meet in Los Angeles, USA.

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!

{ 20 comments }

Last year ICANN allocated the last five IPv4 blocks to the Regional Internet Registries (RIRs). Since then we have seen a concerted effort on the part of network and content providers to make sure they support IPv6, so they’ll be ready for the next few billion Internet users. But there’s another Internet number resource which is running short: 16-bit Autonomous System Numbers (ASNs).

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.

{ 8 comments }

(Oscar Robles, LACTLD Chair)

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.

{ 0 comments }

Resolvers are servers on the Internet which use the Domain Name System (DNS) protocol [TXT, 120 KB] to retrieve information from authoritative servers and return answers to end-user applications. They’re often found in enterprise and ISP networks, and there are a number of public resolver services provided by people like Google and OpenDNS. It’s also possible to configure your own computer to be a resolver, or to deploy your own in your own network using free software like ISC BIND9 and NLNet Labs’ unbound.

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.

[read the rest…]

{ 7 comments }

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.”

{ 0 comments }

Offers to Assist in Securing DNS

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.

{ 0 comments }

OK, so not quite in your pocket. But near your pocket.

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.

{ 0 comments }

Recent legal actions (Rustock, Coreflood and Kelihos, among others) resulting in disrupting or dismantling major criminal networks have involved seizures of domain names, DNS name server reconfiguration and transfers of domain name registrations as part of the takedown actions.

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.

{ 18 comments }

This is a guest post by Mirjam Kühne, Labs Community Builder at the RIPE NCC. RIPE Labs is a platform designed by the RIPE NCC for network operators, industry experts and the RIPE NCC to expose, test and discuss innovative Internet-related tools, ideas and analysis.

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).

{ 5 comments }