As of 00:00 UTC today – 4 days after the launch of the Fast Track Process we have new requests coming in.

The total number is 10 requests. They spread over 5 different languages.

Details about the process is at: http://www.icann.org/en/topics/idn/fast-track/

Please keep asking questions. Is there is anything we can explain better? The FAQ will be updated shortly to include everything you ask here as well.

A number of people testified, including my colleague Doug Brent, but it is the testimony of Steve DelBianco I found particularly intriguing. His testimony revolved around the notion the country-code top-level domains are “controlled by governments”, and future IDN fast track ccTLD allocations will be “reserved only for governments”.

I think many in the ccTLD community will be puzzled by these repeated assertions in his testimony.

Let’s set the stage a little. Country-code top-level domains have existed since the mid-1980s — they are the domains that currently end with two-letter extensions like .FI for Finland, and .DE for Germany. Each country has one available for their use, taken from the ISO 3166-1 standard, but at present they are all written in the letters used for English, known as Latin characters. One of ICANN’s key current initiatives is to work on allowing country-codes to be deployed in different scripts, such as those used for Chinese, Russian and Arabic languages. It is not terribly convenient for those who type in these languages to have to switch their computer to using Latin characters just to put the two-letter endings on their domains, and this will address that.

Recognising that coming up with a complete solution for these internationalised country codes will take some time, the community is working on a “fast track” programme which allows countries that have a demonstrated immediate need to get early access to using these domains. Applications will need to show that the strings they would like to use (like .рф, .日本国 or .ελ) are not contentious, in addition to meeting all the existing eligibility criteria we use for assigning the Latin-based country codes.

So what are the criteria we use today?

The criteria we use in large part revolve around the consensus of “local Internet community” — a sometimes nebulous concept, to be sure, but in essence recognising it is the Internet community as a whole in the country that should decide how their domain is run, not just the Government.

IANA Staff wrote in 1994 that we assign country code top-level domains to trustees that “carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job”, and have a “duty to serve the community”. “Significantly interested parties in the domain should agree that the designated manager is the appropriate party.”

With respect to national governments, in 1997 we noted that “an additional factor has become very important since [1994]: the desires of the government of the country.  The IANA takes the desires of the government of the country very seriously, and will take them as a major consideration in any transition discussion.” Subsequent to that, the ICANN Governmental Advisory Committee has also made statements regarding this principle.

Clearly national governments have an important role in country-code top-level domains, but that does not translate to controlling them. It is the local Internet community that we look to to provide guidance on how their domains should be run. We expect governments are an important actor in the local Internet community, and that they are involved in the discussion and decision making. But there is a key difference between that, and them exclusively controlling the domain, or having them reserved for the government’s use. If the top-level domain for a particular country is assigned to its government to operate directly, it is because the local Internet community consensus there has decided that is what is appropriate, versus some other alternative.

A basic description of the evaluation criteria we use are provided in the public summary delegation reports we publish on the IANA website (see here for a recent example). ICANN staff have also been working in recent months on improving the public delegation documentation, in anticipation of the launch of the fast track programme. This documentation will better elaborate our existing processes. It is our hope that this will assist prospective applicants for these domains better understand the evaluation criteria when they submit their applications.

We know that Internet communities in a number of countries are already discussing how best to run a potential fast track internationalised domain, so that they can be ready to present their consensus should the programme be launched. Until then, all countries of the world have their two-letter ASCII code and ICANN continues to receive requests to maintain and transfer these domains in accordance with the community’s wishes.

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.

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.

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.

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

How does the DNS work?

The DNS can be considered to be a question-and-answer system. When you type in an address like “icann.org” into a web browser, your computer needs to turn that into a numeric address of the computer hosting that website. To do this, it sends a question over the Internet to a DNS server “Where is icann.org?” The DNS server sends back an answer, “The address is 192.0.2.0”.

How do you attack the DNS?

Let’s say I want to execute an attack on this question and answer exchange, in order to convince the computer to go to the wrong address. When the computer I wish to attack asks a question, my goal is to provide a fake response back to that computer quicker than the real server comes back with the response. By getting my forged answer back faster, the computer will proceed using my answer, rather than the official one.

So, if I send back a fake address to a computer, I can get that computer to go to a different address than the one intended. For example, on that address I might have set up a fake website intended to take someone’s sensitive data, like a replica of a bank’s website.

If I manage to attack one computer why is that a big deal?

A successful attack on one computer in isolation can be problematic for the user of that computer, but it is not that interesting to an attacker to succeed against only one person. Unlucky for us, just one successful attack can very easily have wider consequences. Let me explain.

The DNS is made much more efficient by the use of “caching” name servers. These name servers sit at ISPs, or on corporate networks, and perform DNS lookups on behalf of customers. It then stores the answers it receives in a cache, so for future lookups for the same domain it does not repeat the lookup – it just remembers the previous answer.

This means that if you execute an attack and it gets stored in a cache, it can actually impact many people over and over again, because that answer will be redistributed to everyone that uses that same caching server.

This is why this type of attack is usually called a “cache poisoning” attack, because by poisoning the cache with the wrong data, it creates a much more serious problem.

So I just send back an answer quicker, and that’s it?

It is not quite as simple as just sending a quicker answer back to a computer, you also have to guess certain attributes correctly on the answer that match the question. For example, your answer needs to go back to the same computer the question originated. You also need match the question that was being asked in your answer.

It is simple, however, to guess most of the attributes. As you know which computer you are trying to attack, you don’t need to guess that. As you know which domain you are trying to impersonate, that is also a given. Conventionally, there are only two variables. One variable is you need to guess which server the answer is coming from. The average domain on the Internet has around two or three name servers, only one of which will respond to any given query. Therefore you have about a one in three chance of guessing that correctly. The second variable is a unique reference number (formally, a “transaction ID”), that has about 65000 possibilities. Therefore you have about a 1 in 65000 chance of guessing that correctly.

Earlier this year, security researcher Dan Kaminsky found that it is devastatingly simple to exhaust all those possibilities in a very short amount of time by performing an attack in a certain way. How short? Well, British DNS researcher John Dickinson did some tests and found that on average he could successfully attack a server in just 1.3 seconds.

How do you fix the problem?

The sad news is there is no real solution as far as the regular DNS is concerned. It is not like a security hole in a piece of software that can be repaired with an update. This is an architectural flaw in the DNS protocol itself. There are patches for DNS software, but these only attempt to make executing an attack more difficult, they don’t solve the problem.

Some of the short term approaches to make attacks more difficult are as follows:

1. Randomise the “source port”. One of the attributes in the packet that an attacker needs to guess is called the port number. For architectural reasons, this needs to be port 53 on the way to the server — this is how the server realises it is a DNS query as opposed to a different type of query. However, the port number that a response is sent back to doesn’t need to be port 53. By randomising this, you make it harder for an attacker to guess. Much of the software updates to this problem in mid-2008 related to adding source port randomisation.
2. Block open recursive name service. If you provide access to a caching name server to the whole Internet, then it is very easy for the whole Internet to execute an attack against your server. If you limit access to just those who need it (i.e. your local network), then you reduce that risk.
3. Experimentation with capitalisation of domains. Domains in practice are not case sensitive – if you type ICANN.ORG or icann.org, it means the same thing. However, inside the DNS protocol itself, the encoded transmission between computers actually is case sensitive. This property can be used to add some more randomness to transmissions. If my computer sends off a question asking about “iCaNn.OrG” and gets back an answer for “icann.org”, it can throw it away as untrustworthy. This approach is still experimental and being discussed.

The net effect of these attempts to reduce the risk of attacks primarily involve adding more randomness for the attacker to guess. These approaches approximately double the number of “bits” of randomness. To be clear though, they only make an attack harder, but an attack is still viable. Furthermore, we know that both network speeds and computer speeds get faster and faster each year. These are the two things that slow down an attacker. Therefore, we know that successful attacks will just be easier and easier into the future.

If there is no short term solution, what is the long term solution?

While the DNS itself can’t be properly fixed for the security problem, a new protocol that overlays the DNS called DNSSEC does. DNSSEC uses a system of certification to show that a DNS answer has not been modified. If someone tries to execute an attack, the certificate won’t validate, and the incorrect answer will be thrown away.

DNSSEC is difficult to deploy. It requires upgrades in DNS servers, it changes the way domain name holders manage their name servers, and it adds extra complexity. However, with the knowledge that DNS attacks are so simple to execute without it, there is growing consensus that the pain it will take to deploy is less than the pain of a DNS that you can no longer trust.

More information

You can view the presentation slides used in Cairo.

As a graduate student at UCLA in the late 1960s, Jon was deeply involved in the ARPANET project, becoming the first custodian of the Request for Comment note series inaugurated by Stephen D. Crocker. He also undertook to serve as the “Numbers Czar” tracking Domain Names, Internet Addresses, and all the parameters, numeric and otherwise, that were key to the successful functioning of the burgeoning ARPANET and, later, Internet protocols. His career took him to the east and west coasts of the United States but ultimately led him to the University of Southern California’s Information Sciences Institute (ISI) where he joined his colleagues, Danny Cohen, Joyce K. Reynolds, Daniel Lynch, Paul Mockapetris and Robert Braden, among many others, who were themselves to play important roles in the evolution of the Internet.

It was at ISI that Jon served longest and as the end of the 20th Century approached, began to fashion an institutional home for the work he had so passionately and effectively carried out in support of the Internet. In consultation with many colleagues but particularly with Joseph Sims of the Jones Day law firm and Ira Magaziner, then at the Clinton administration White House, Jon worked to design an institution to assume the IANA responsibilities. Although the path to its creation was rocky, the Internet Corporation for Assigned Names and Numbers (ICANN) was officially created in early October, 1998, just two weeks before Jon’s untimely death on October 16.

In 1998 there were an estimated 30 million computers on the Internet and an estimated 70 million users. In the ensuing decade, the user population has grown to almost 1.5 billion and the number of servers on the Internet now exceeds 500 million (not counting episodically connected laptops, personal digital assistants and other such devices). As this decade comes to a close, the Domain Name System is undergoing a major change to accommodate the use of non-Latin character sets in recognition that the world’s languages are not exclusively expressible in one script. A tidal wave of newly Internet-enabled devices as well as the increasing penetration of Internet access in the world’s population is consuming what remains of the current IPv4 address space, driving the need to adopt the much larger IPv6 address space in parallel with the older one. Over three billion mobiles are in use and roughly 15% of these are already Internet-enabled.

Jon would take considerable satisfaction knowing that the institution he worked hard to create has survived and contributed materially to the stability of the Internet. Not only has ICANN managed to meet the serious demands of Internet growth and importance in all aspects of society, but it has become a worked example of a new kind of international body that embraces and perhaps even defines a multi-stakeholder model of policy making. Governments, civil society, the private sector and the technical community are accommodated in the ICANN policy development process. By no means a perfect and frictionless process, it nonetheless has managed to take decisions and to adapt to the changing demands and new business developments rooted in the spread of the Internet around the globe.

Always a strong believer in the open and bottom-up style of the Internet, Jon would also be pleased to see that the management of the Internet address space has become regionalized and that there are now five Regional Internet Registries cooperating on global policy and serving and adapting to regional needs as they evolve. He would be equally relieved to find that the loose collaboration of DNS root zone operators has withstood the test of time and the demands of a hugely larger Internet, showing that their commitment has served the Internet community well. Jon put this strong belief into practice as he was founder and ex-officio trustee of ARIN.

As the very first individual member of the Internet Society he helped to found in 1992, Jon would certainly be pleased that it has become a key contributor to the support of the Internet protocol standards process, as intended. The Internet Architecture Board and Internet Engineering and Research Task Forces as well as the RFC editing functions all receive substantial support from the Internet Society. He might be surprised and pleased to discover that much of this support is derived from the Internet Society’s creation of the Public Internet Registry to operate the .ORG top level domain registry. The Internet Society’s scope has increased significantly as a consequence of this stable support and it contributes to global education and training about the Internet as well as to the broad policy developments needed for effective use of this new communication infrastructure.

As a computer scientist and naturalist, Jon would also be fascinated and excited by the development of an interplanetary extension of the Internet to support manned and robotic exploration of the Solar System. This very month, the Jet Propulsion Laboratory will begin testing of an interplanetary protocol using the Deep Impact spacecraft now in eccentric orbit around the sun. This project began almost exactly ten years ago and is reaching a major milestone as the first decade of the 21st Century comes to an end.

It is probable that Jon would not agree with all the various choices and decisions that have been made regarding the Internet in the last ten years and it is worth remembering his philosophical view:

“Be conservative in what you send and liberal in what you receive.”

Of course, he meant this in the context of detailed protocols but it also serves as a reminder that in a multi-stakeholder world, accommodation and understanding can go a long way towards reaching consensus or, failing that, at least toleration of choices that might not be at the top of everyone’s list.

No one, not even someone of Jon’s vision, can predict where the Internet will end up decades hence. It is certain, however, that it will evolve and that this evolution will come, in large measure, from its users. Virtually all the most interesting new applications of the Internet have come, not from the providers of various Internet-based services but from ordinary users with extraordinary ideas and the skills to try things out. That they are able to do this is a consequence of the largely open and non-discriminatory access to the Internet that has prevailed over the past decade. Maintaining this spirit of open access is the key to further development and it seems a reasonable speculation that if Jon were still with us, he would be in the forefront of the Internet community in vocal and articulate support of that view.

A ten-year toast seems in order. Here’s to Jonathan B. Postel, a man who went about his work diligently and humbly, who served all who wished to partake of the Internet and to contribute to it, and who did so asking nothing in return but the satisfaction of a job well done and a world open to new ideas.

Vint Cerf
Woodhurst
October 2008

So where is IPv6 deployment most evident? It?s a very difficult thing to measure. It is difficult to measure the amount of IPv6 traffic as so much of it is tunneled inside of IPv4. And anyway, tunneled traffic is probably from end users rather than ISPs, but we need ISPs to deploy IPv6 to allow the Internet to grow. So how can we see where ISPs are deploying IPv6 in their networks?

One possible measure of IPv6 deployment in ISPs is the number of IPv6 address blocks (prefixes) seen in the routing table in comparison with the the number of autonomous systems (ASs – roughly equivalent to ISPs) in a region. Geoff Huston has a regional breakdown of advertised ASs on his web site and the SixXS project has a regional breakdown of the IPv6 address blocks visible per region on its web site.

AfriNIC, the Regional Internet Registry for Africa and parts of the Indian Ocean, has a higher proportion of networks in its region announcing IPv6 addresses than the others. Africa also has a smaller deployed base but IPv6’s size is designed to support exactly the kind of network growth that highly populated areas, like Africa and Asia will see as their deployed base grows in the next few years.

Proportion of ASs in RIPE NCC service region announcing IPv6 prefixes

Proportion of ASs in APNIC service region announcing IPv6 prefixes

Proportion of ASs in ARIN service region announcing IPv6 prefixes

Proportion of ASs in LACNIC service region announcing IPv6 prefixes

Proportion of ASs in AfriNIC service region announcing IPv6 prefixes